test(plan): cover prefix-index range correctness - #26852

I found two correctness blockers. Both can still let a lossy prefix key exclude valid rows before the base-table predicate is evaluated.

1. P1 — scoped FORCE hints bypass the new guards. applyForceIndexHints runs before ordinary filter index selection. For FORCE INDEX FOR ORDER BY/GROUP BY, applyForceIndexHintToScan calls tryHintedIndexAccess, and tryHintedCoveringIndexScan treats a prefix part as a complete covered column and rewrites the original filter onto serial_extract(hiddenKey, ...). It then protects the base scan, so the guard added in tryIndexOnlyScan is never reached. I reproduced this at the exact PR head with:

CREATE TABLE t(id INT PRIMARY KEY, a VARCHAR(32), KEY idx_a(a(3)));
SELECT id FROM t FORCE INDEX FOR ORDER BY(idx_a)
WHERE a BETWEEN 'abcX' AND 'abdA' ORDER BY a;

The planner still produces an idx_a covering scan carrying the range on the truncated key. Besides under-fetching, a prefix key cannot provide full-value ORDER/GROUP ordering among values sharing the same prefix. Please centralize the lossy-prefix eligibility contract (or reject these hinted covering/order/group paths) and add scoped-hint regressions with same-prefix values.

2. P1 — semantically stale prefix metadata fails open. indexHasLossyLeadingPrefix only fails closed on parse errors; it returns prefixLengths[ResolveAlias(Parts[0])] > 0. On the current base, ALTER TABLE ... RENAME COLUMN is INPLACE and updates IndexDef.Parts/mo_indexes.column_name, but does not rename the key inside algo_params.prefix_lengths. A valid state such as Parts=["new_name", ...] plus {"prefix_lengths":"old_name:3"} therefore returns false here, while the existing physical index rows are still truncated. The new range maps can then select that index and reproduce the same wrong-result bug after a normal DDL operation. This also contradicts the PR claim that malformed metadata fails closed. Please keep prefix metadata synchronized on rename and treat orphan/mismatched prefix keys conservatively; cover rename + range before/after flush and subsequent DML.

The focused tests added by this PR pass locally, and git diff --check is clean, but they do not exercise either bypass.

Reviewed the complete current diff at c7e56fcf00956e540d2522bf94b695f6faefad41 (base df49b097935ccd650d9f30016d5219228e053c5e).

No blocking correctness issue found. The added coverage exercises the previously unsafe declared-prefix range paths across FORCE/IGNORE, scalar and paired ranges, OR/IN, prepared statements, unique indexes, flush, rename/DML, scoped ORDER/GROUP hints, malformed metadata, and a complete-index control. Expected plans and result sets are consistent with the fail-closed prefix-index contract. The test-only change adds no production ownership, wait, or lifecycle edge.

I also integrated this head with current latest main f9a3184c3ae251810265aef90baa7aaa8047fe23 (the regular-index cost refactor): merge was conflict-free, focused tests passed 10x, and go test ./pkg/sql/plan -count=1 -timeout=300s passed.