feat(vitess): add VSchema change tracking

[aparajon]

Why

When DDL and VSchema changes coexist in a deploy, VSchema progress is invisible — it only lives in the deploy request's metadata but doesn't surface through the progress API or TUI. Users see DDL tables completing but have no idea VSchema is being applied.

What

VSchema task tracking:

• Always create VSchema tasks alongside DDL tasks (not just for VSchema-only deploys)
• Add CHANGE_TYPE_VSCHEMA to proto ChangeType enum
• Track VSchema task state through deploy lifecycle: pending → running (during in_progress_vschema) → revert_window → completed
• Extract engine.MessageApplyingVSchema constant for deploy phase detection
• Set ChangeType on progress response TableProgress
• VSchema task state transitions logged to apply_logs

TUI/progress fixes:

• Fix table flicker before deploy prompt (IsBranchSetupPhase override, skip VSchema tasks in markTasksRunning)
• Clamp per-table status to revert_window during revert window for cross-keyspace consistency
• Fix Progress handler prematurely marking apply complete in sequential mode (broke make demo)
• Remove recycle emoji from cutover labels
• vschemaStatusLabel handles all deploy states (no raw state strings in TUI)

Tests:

• TestDeriveOverallState — revert window, mixed states, priority ordering
• TestDeriveVSchemaTaskState — full lifecycle: pending → running → revert_window → completed
• TestVSchemaTasksCreatedAlongsideDDL — VSchema tasks created for every namespace with VSchema data
• TestVSchemaStatusLabel — all deploy states produce human-readable labels
• TestVitess_Apply_VSchemaTaskTracking (e2e) — polls progress API, verifies VSchema tasks appear with change_type=vschema_update and reach terminal state
• TestLocal_Apply_CreateMultipleTables (e2e) — multi-table sequential apply completes all tasks
• Fix e2e cleanup ordering (drop tables before resetting VSchema)

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds first-class tracking and surfacing of Vitess VSchema changes through the deploy lifecycle so mixed DDL+VSchema deploys show VSchema progress in the progress API/TUI.

Changes:

• Introduces CHANGE_TYPE_VSCHEMA in the Tern proto and maps task DDLAction → ChangeType in progress responses.
• Always creates synthetic VSchema tasks for namespaces with VSchema changes (including mixed DDL+VSchema deploys) and adds task-state derivation for VSchema tasks.
• Updates CLI preview output and adds tests for VSchema labels, rendering order, and proto round-trips.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
pkg/tern/state_converters.go	Adds ddlActionToProtoChangeType to map task DDLAction strings (including vschema_update) to proto ChangeType.
pkg/tern/local_client.go	Always appends VSchema tasks during Apply and sets TableProgress.ChangeType in Progress responses.
pkg/tern/local_apply.go	Adds special handling and state derivation for VSchema tasks during atomic progress syncing.
pkg/proto/tern.proto	Adds CHANGE_TYPE_VSCHEMA and updates ChangeType comment to “schema change”.
pkg/proto/ternv1/tern.pb.go	Regenerated protobuf output reflecting the new enum value.
pkg/cmd/templates/progress_states_test.go	Adds tests for VSchema labels, rendering order, and VSchema task detection variants.
pkg/cmd/templates/preview_progress.go	Updates the Vitess progress preview to include mixed DDL + VSchema scenarios.
pkg/api/proto_helpers.go	Adds CHANGE_TYPE_VSCHEMA ↔ vschema_update conversions.
pkg/api/proto_helpers_test.go	Extends ChangeType round-trip test to cover VSchema.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.