feat(plan): support ALTER TABLE AUTO_INCREMENT = value

[VioletQwQ-0]

What type of PR is this?

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

Which issue(s) this PR fixes:

issue #23143

What this PR does / why we need it:

This PR continues the unfinished work from #24531 while preserving the original commits and authorship.

It implements ALTER TABLE ... AUTO_INCREMENT = N across planning, execution, allocator state, COPY ALTER, schema epochs, recovery, and regression coverage.

The takeover review also closes the two remaining P1 invariants:

• COPY allocator reconciliation now carries source state by stable destination column identity, including drop/add/reorder/rename and hidden fake-PK movement, instead of mixing source and destination positional indexes;
• legacy CN writes without the epoch presence bit are treated as epoch zero, so they remain compatible before the first fenced ALTER but fail closed after the table epoch advances.

Validation:

• GitHub reports the PR mergeable against current main;
• go test -count=1 passed for pkg/sql/colexec/table_clone, pkg/sql/compile, pkg/vm/engine/tae/rpc, and pkg/vm/engine/tae/txn/txnimpl;
• go vet and go build passed for the same affected packages;
• focused race tests passed 10 consecutive runs for COPY identity reconciliation and TN epoch convergence;
• changed-commit whitespace checks passed.

[XuPeng-SH]

Blocking finding

P1 — Make MEMKV recovery delivery cancellation-aware (pkg/txn/storage/mem/kv_txn_storage.go:180)

replica.close() now calls CancelRecovery() and then waits for Start() to publish startedC. The recovery consumer exits when that context is canceled, but KVTxnStorage.StartRecovery still performs an unconditional c <- klog.Txn for every replayed user record. Since txnC has capacity 16, canceling after the consumer exits while more than 16 records are replayed leaves the producer blocked forever. It cannot return or close txnC, Start() cannot finish, and replica.close() hangs.

Please make each MEMKV recovery send cancellation-aware, as the TAE implementation already is:

select {
case <-ctx.Done():
    return
case c <- klog.Txn:
}

Please also add a regression that replays more than cap(txnC) records, cancels recovery after the consumer stops, and asserts startup/replica close completes.

[VioletQwQ-0]

@XuPeng-SH @gouhongshen Addressed the MEMKV recovery cancellation finding in 6c44b46. StartRecovery now selects on ctx.Done() for every transaction delivery, so cancellation terminates even when the 16-entry txn channel is full after the consumer exits. Added TestRecoveryCancellationUnblocksFullTxnChannel with 17 replay records; it reproduced the pre-fix hang and now passes. Validation: full pkg/txn/storage/mem, pkg/txn/service, and pkg/tnservice tests; focused race tests across storage/service/replica cancellation; go vet/build for all three packages; git diff --check; unhappy-path Q1-Q3 and mo-self-review.

[VioletQwQ-0]

@fengttt Thank you for calling this out. You are right: even though transaction fencing and recovery are related to the intended correctness guarantee, putting all of them together with the SQL feature made this PR far too large to review reliably. The description also failed to explain which changes were prerequisites and which were general recovery fixes. I am sorry for creating that review burden.

I have closed this PR and will not reopen or rewrite its branch. I am rebuilding the work from the latest main, with one independently reproducible invariant per PR and serial dependencies so reviewers never need to read an accumulated stack.

Split tracker:

• fix(txn): restore recovery routes and cancellation #25956 — restore incomplete recovery participant routes and make TN startup recovery cancellable (merged; fixed TN recovery can use incomplete participant routes and block shutdown #25951)
• prepared/committing 2PC replay assessment — no separate PR: the current TAE recovery producer remains disabled/unimplemented, so only the minimal replay state required by the fence is kept in its own prerequisite
• feat(auto-increment): add transactional epoch fence #26027 — AUTO_INCREMENT epoch fence prerequisite (Draft; full CI and independent review pending)
• transactional allocator offset reset
• COPY/CLONE allocator reconciliation
• final ALTER TABLE ... AUTO_INCREMENT=N SQL entry point (Fixes #23143)

The generic recovery items are being reproduced on current main and tracked independently. The feature prerequisites will reference #23143, while only the final user-facing PR will close it. Each PR will start as draft, stay within a small handwritten diff, list explicit non-goals, and pass focused tests plus self-review before being made ready.

I will update this same tracker as the serial PRs are merged instead of adding repeated status comments.