feat(analysis): name RETURNING columns from their aliases

[omer-cengel]

Summary

A RETURNING column on INSERT, UPDATE, or DELETE can now carry an alias that names its generated result component, the same way a SELECT item's alias does. Previously every aliased RETURNING item was rejected, so a returning write could not choose its result component names.

Changes

• A returned direct column written as id AS user_id, id user_id, a quoted alias such as id AS "User Id", or a column qualified through the target's alias such as u.id AS uid is named by its alias. Its Java type, nullability, enum, and array facts still come from the schema column.
• A returned column list, aliased or not, keeps the query's own <QueryName>Result record. Only a bare, unaliased RETURNING * returns the table's shared <TableName>Row record.
• An aliased wildcard (RETURNING * AS x or RETURNING * x) is rejected as RETURNING * must not be aliased..
• Parameter order, binding order, selected-column order, and the executed SQL, including the alias text, are unchanged.
• Analyzer tests cover each write statement and alias spelling. A compiler test compiles a generated repository with alias-named components, and a PostgreSQL test reads aliased components from executed returning writes.
• The query documentation describes the accepted alias forms and the remaining rejections.

Scope and non-goals

• Computed or cast RETURNING items stay rejected with or without an alias, as does a qualified table.* with or without an alias.
• No changes to Java generation or the runtime. Aliased returned columns flow through the existing result-column naming and positional row mapping.