feat: share one row record per table across full-row queries

[omer-cengel]

Summary

Queries that return one complete table row now return a reusable nested <Table>Row record in their repository instead of a separate per-query result record. Create, read, and list operations on the same table therefore share one Java type, such as AuthorRepository.AuthorsRow, and application code no longer converts between identical per-query records.

Changes

• A SELECT with exactly one source whose only projection item is * or <source>.*, and an INSERT, UPDATE, or DELETE whose RETURNING clause is exactly *, return the repository's <Table>Row record. Aliases and table-name spelling in the query do not affect which row type is used.
• Each such table gets one nested public record <Table>Row in schema column order, with lower-camel-case components (for example createdAt), and one private positional row mapper. Both are generated once, after the repository constructor, in the order queries first use them.
• Row names are normalized from the table name and never singularized, so authors generates AuthorsRow and authorsRowMapper. A row mapper yields to a query's own mapper with a numeric suffix, so a query named Authors keeps authorsRowMapper and the row mapper becomes authorsRowMapper1. Method parameters avoid all row-mapper names.
• Two tables in one repository whose row types are equal ignoring case are rejected before any file is written, naming both tables and both types.
• The Maven/PostgreSQL sample now uses RETURNING * and SELECT *, so createAuthor, getAuthor, and listAuthors all return AuthorRepository.AuthorsRow. The README, quickstart, query, and configuration documentation describe the rule, naming, and collisions.
• Analyzer, generator, compile, and PostgreSQL integration tests cover shared and per-table row records, mapper disambiguation, and the collision error.

Scope and non-goals

• Explicit column lists (even ones naming every column), a wildcard combined with another projection item, wildcards in joins, and RETURNING column lists keep their query-specific <Query>Result records, with unchanged alias naming and selected-column order.
• Method parameter order and JDBC binding order are unchanged.
• Query cardinality, null semantics, the runtime executor, RETURNING aliases, structural deduplication of result records, and configuration options are unchanged.