release-25.4: sql: fix identity computed columns with projection with generic plans

[ZhouXing19]

Backport 1/1 commit from #162036

---

Previously, when a computed column was defined as a identical to another column (e.g., vcol AS (col)), and a generic plan was used with a lookup join on an index containing that column (vcol), the query would fail with "cannot map variable %d to an indexed var".

This occurred because the Factory.Replace function doesn't invoke the replacement callback for leaf nodes like VariableExpr, as it only traverses children. Thus, with the computed column expression a simple VariableExpr, table column references weren't getting replaced with their corresponding placeholder columns. As a result, when constructing the projection, we went through the MergeProjectWithValues rule incorrectly.

This fix adds special handling in the constraint builder to directly apply the replacement function when the computed column expression is a simple VariableExpr, ensuring table columns are properly replaced with their corresponding placeholder columns.

Fixes #161978

Release note (bug fix): Fixed an error that occurred when using generic plan that generates a lookup join on indexes containing identity computed columns.

---

Release justification: Resolve a correctness issue where queries using identity computed columns with generic plans would fail with an error, preventing customers from executing valid queries.

[blathers-crl]

Thanks for opening a backport.

Before merging, please confirm that it falls into one of the following categories (select one):

• Non-production code changes. Includes test-only changes, build system changes, etc.
• Fixes for serious issues. Defined in the policy as correctness, stability, or security issues, data corruption/loss, significant performance regressions, breaking working and widely used functionality, or an inability to detect and debug production issues.
• Other approved changes. These changes must be gated behind a disabled-by-default feature flag unless there is a strong justification not to.

Add a brief release justification to the PR description explaining your selection.

Also, confirm that the change does not break backward compatibility and complies with all aspects of the backport policy.

All backports must be reviewed by the TL and EM for the owning area.

[trunk-io]

Merging to release-25.4 in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

[cockroach-teamcity]

This change is 

[blathers-crl]

✅ PR #162139 is compliant with backport policy

Confidence: high
Critical bug criteria met: [Bugs that can cause the DB to return incorrect results or result in suboptimal performance]
Backward compatible: true
Explanation: The pull request is compliant with the backport policy because it addresses a critical bug that affects database correctness, specifically in handling queries using identity computed columns with generic plans. This scenario falls under the critical bug criteria of 'Bugs that can cause the DB to return incorrect results or result in suboptimal performance'. The 'Release justification:' in the PR body explicitly mentions that this change resolves a correctness issue where customers could encounter errors executing valid queries using computed columns with certain plans, supporting the critical bug fix justification. The changes involve code related to the SQL optimizer's execution and tests but do not appear to introduce any backward compatibility issues. The provided justification and the nature of the bug (affecting the correctness of query execution) are adequate for a direct backport without the need for a feature flag, as allowed by the policy for critical bug fixes.

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}