Denorm OPTIONAL count(a) on the anchor dangles (a.code vs __denorm_scan_a's Origin); composite-VLP SQL malformed (follow-ups to #659)

[genezhang]

Two pre-existing residuals surfaced during the #682 (#659) adversarial review. Both are byte-identical to main (NOT introduced by #659); #659 deliberately left them untouched.

Residual 1 — denorm OPTIONAL count(a) on the ANCHOR dangles

MATCH (a:Airport) OPTIONAL MATCH (a)-[:FLIGHT*2..3]->(b:Airport) RETURN count(a) (aggregating the ANCHOR a, not the far endpoint) renders count(a.code) against the __denorm_scan_a node-scan CTE, which projects Origin (the physical column) not code (logical) → dangling.

This goes through the anchor-alias / __denorm_scan_a path, NOT the VLP CTE endpoint rewriter (rewrite_render_expr_for_vlp_with_endpoint_info) that #659 fixed — so #659's miss-fallback id-resolution doesn't reach it. Fix direction: apply an analogous logical-id→physical resolution (or the canonical scan-CTE id column) at the __denorm_scan_a projection site. Adjacent to #644 (the denorm OPTIONAL-VLP anchor-join family).

Residual 2 — composite-id VLP SQL broadly malformed

Composite-id VLP CTEs (e.g. AirportComposite with node_id: [code, state] on schemas/dev/flights_denorm_mixed_sources.yaml) emit unquoted composite-comma column references throughout the CTE — a pre-existing composite-VLP defect. #659 correctly leaves composite loud/untouched per #605 discipline (the !is_composite() guard). Tracked with #604/#605/#627/#631 composite-VLP family.

Both are loud/dangling (ground-rule-1 safe), not silent-wrong.

[genezhang]

Residual 1 investigated — root caused, but the clean-reuse fix is BLOCKED (needs traversal generalization)

Confirmed the exact mechanism. count(a) (bare, on the denorm OPTIONAL-VLP anchor) is normalized by projection_tagging (src/query_planner/analyzer/projection_tagging.rs:1756-1763) to count(a.<node_id.columns().first()>) = count(a.code) using the LOGICAL node_id. For a denorm node, code is logical but the __denorm_scan_a CTE exposes the role-mapped physical origin_code → dangling. Standard schemas are unaffected (logical == physical there).

Discriminator (verified with cg):

• RETURN count(a) → count(a.code) ✗ (dangles)
• RETURN count(a.code) explicit → count(a.origin_code) ✓ (the .code is property-mapped upstream before the aggregate)
• WITH count(a) AS c RETURN c → count(a.origin_code) ✓ (the WITH path runs the anchor-id resolver)
• RETURN a.code, count(*) direct → a.origin_code ✓

So the gap is specifically the plain-RETURN aggregate over the anchor; the WITH-aggregate path already resolves it.

Attempted fix + why it's blocked: the natural fix is to run the same resolution the WITH path uses — denorm_scan_cte_anchor_id_property(plan, alias) (plan_builder_utils.rs:3981) — inside select_builder::resolve_denorm_refs_in_expr (which IS called for this expression, verified). BUT that helper returns None for the plain-RETURN plan tree: its internal find_inner_optional_denorm_graphrel traversal (plan_builder_helpers.rs) is scoped to the WITH-clause plan shape (documented guards for the Union-wrapped bidirectional/OPTIONAL forms). The plain-RETURN tree differs, so the helper doesn't recognize the anchor. Reverted the partial attempt (kept loud, no regression) rather than generalize the traversal without careful review — it carries regression risk in the denorm anchor area.

Fix direction for a dedicated pass: either (a) generalize denorm_scan_cte_anchor_names_and_id_col's traversal to also match the plain-RETURN aggregate plan shape, or (b) resolve a.<logical_id> → the from-role physical column directly from the connecting rel's from_node_properties/to_node_properties (role = whether the anchor is the VLP start/from side) at the resolve_denorm_refs_in_expr site. Both need to preserve the existing #510/#529/#582 anchor-id guards. Same "logical node_id vs physical column in count-normalization" family as #659 (#682), but on the ANCHOR path rather than the VLP-endpoint path. Loud/ground-rule-1 safe throughout.

[genezhang]

Residual 1 FIXED by #685 (f8a69ad7). count(a) on the denorm OPTIONAL-VLP anchor now resolves the logical node_id to the __denorm_scan_a CTE's physical column (count(a.origin_code)).

Fix reused #644's rewrite_denorm_optional_vlp_anchor_scan machinery — which already computes the anchor's physical id column and rewrites the VLP JOIN key — extending it to mirror the same (anchor_alias, logical_id) → physical_id rewrite across the SELECT/GROUP BY/HAVING/ORDER BY (via the exhaustive map_render_expr). All of #644's guards preserved: end-anchored/reversed, composite, anchor-gate, chained-VLP shapes stay loud unchanged. Adversarial review 0 blockers (verified guard chain airtight + no over-fire via main-vs-PR differential). +1 curated + 2 corpus goldens.

Residual 2 (composite-VLP malformed SQL) remains open under this issue — separate #604/#605/#627 composite-VLP family.