fix(frontend): quote prepared statement names during migration

[LeftHandCold]

What type of PR is this?

• API-change
• BUG
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes:

issue #25903

What this PR does / why we need it:

Prepared statement migration sends the normalized statement name and inner SQL
to the target CN. The target reconstructed textual PREPARE statements by
interpolating the normalized name without identifier quoting. A valid source
statement such as:

prepare `a-b` from select 1

was therefore replayed as invalid SQL:

prepare a-b from select 1

Quote the normalized name with the shared sqlquote.Ident helper before
replay. This also doubles embedded backticks, preserving the identifier and the
SQL statement boundary without changing the migration protobuf.

The regression test follows the real source parser and target migration path
for:

• ordinary names;
• names containing -;
• reserved words;
• names containing an embedded backtick.

Validation:

• .agents/skills/mo-dev/scripts/mo-cgo-test -count=1 -timeout=120s -run '^TestSession_Migrate$' ./pkg/frontend
• .agents/skills/mo-dev/scripts/mo-cgo-test -count=1 -timeout=240s ./pkg/frontend
• go test -count=1 ./pkg/common/sqlquote
• go build ./pkg/frontend (with the repository CGo environment)
• go vet ./pkg/frontend (with the repository CGo environment)

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[XuPeng-SH]

Quoting fixes the first replay for ordinary quoted names, but the recreated statement is not migration-safe for a valid reserved-word name. Details are attached inline.

[XuPeng-SH]

[P2] Preserve the inner SQL for names containing from

This branch still has the substring-based delimiter extraction in doPrepareStmt. For a valid source name such as prepare `from` from select ?, this reconstructed SQL parses and the first migration returns success, but doPrepareStmt matches the from inside the quoted identifier and stores PrepareStmt.Sql as from select ? instead of select ?. migrateConnectionFrom then serializes that corrupted value, so the next CN migration replays prepare `from` from from select ? and fails to parse. I reproduced this by adding the from case to the existing full TestSession_Migrate/ok path and asserting the stored SQL: expected select ?, actual from select ?. Please close the repeated-migration path (for example by integrating the token-based delimiter fix) and add a regression that verifies the stored SQL or performs two migrations.

[gouhongshen]

Codex automated review

Valid quoted names containing from cannot survive a second CN migration.

P1 - Preserve inner SQL for names containing from (pkg/frontend/session.go:2076)

For Name from and SQL select ?, this builds prepare from from select ?. The first replay succeeds, but doPrepareStmt (pkg/frontend/mysql_cmd_executor.go:1545) finds the first from inside the quoted identifier and stores Sql as from select ?. migrateConnectionFrom serializes that corrupted field, so the next migration builds prepare from from from select ?, which cannot parse as PREPARE requires a prepareable statement after its delimiter. Fix delimiter extraction and add a two-hop migration or stored-SQL regression; the current select case misses this.

[gouhongshen]

Codex automated review

No findings. The prior from-in-quoted-name regression is resolved by token-based delimiter extraction, and the migration tests cover reserved, punctuated, and embedded-backtick names. Focused tests could not run because go is unavailable in this environment.