feat: resolve record components as DTO fields

[tangcent]

Summary

Closes #139.

The Java parser only walked class_declaration and interface_declaration nodes, so a record used as a request or response DTO contributed zero fields: record components are formal_parameter nodes under the declaration's formal_parameters, not field_declaration nodes, and nothing looked for record_declaration at all. A DTO written in the now-standard form

public record CreateUserRequest(String name, String email, int age) {}

exported a request body with no fields. Records are the default DTO style in modern Java codebases, so this silently affected a large share of real projects.

This PR teaches the parser records and lets them resolve through the existing class registry and type resolver unchanged.

Changes

File	Change
api-collector-java/parser/extractor.go	New extractRecord reads the name, annotations, type parameters, and implements clause off record_declaration — records reuse the same super_interfaces and type_parameters nodes as classes, so the existing extractors apply unchanged. New extractRecordComponents converts formal_parameter components to fields by reusing extractParameter, so component annotations and doc comments come through exactly like method parameters. IsFinal stays unset even though components are implicitly final, because the resolver skips final fields (#141 covers that rule itself) — marking them would have dropped every record field again. The optional record body (compact constructors, methods, static members) is ignored rather than parsed, so it cannot cause parse failures
api-collector-java/parser/parser.go	record_declaration joins class and interface in extractAllClasses
api-collector-java/testdata/CreateUserRequest.java	Plain record fixture (the issue's acceptance example)
api-collector-java/testdata/PageResponseRecord.java	Generic record fixture (PageResponseRecord<T>(List<T> items, int page, int total))
api-collector-java/testdata/ValidatedUserRecord.java	Record with bean-validation annotations on components plus a compact constructor and a body method
api-collector-java/parser/parser_test.go	TestParser_ParseRecord over the three fixtures: field names/types, package, type parameters, component annotations (@NotNull, @Size(min, max)), record JavaDoc, and proof that the compact constructor and body method do not become fields
api-collector-java/resolver/resolver_test.go	TestResolve_SimpleRecord (record resolves to an object model with name/email/age) and TestResolve_GenericClassRecord (PageResponse<Order> binds T so items resolves to an array of Order objects with their own fields)
api-collector-java/springmvc/parser_test.go	TestParser_RecordRequestBody: end-to-end over real source — a controller taking a record as @RequestBody exports a request body schema with name, email, and age

Records register in the class registry like any class, so generic records resolve through the existing type-parameter binding machinery with no resolver changes.

Verification

• go test ./... passes for all 13 workspace modules, and go vet ./... is clean for api-collector-java.
• Acceptance criteria from the issue:
  • public record CreateUserRequest(String name, String email, int age) as @RequestBody exports a request body with name, email, and age (TestParser_RecordRequestBody).
  • Existing class-based DTO tests still pass (full suite green, no golden files affected — this change is Java-collector-only and the CLI golden project is Go).

[github-actions]

📦 Build artifact for this PR is available in the GitHub Actions workflow run under Artifacts.