fix(migrations): resolve VCS prefix collision (213-215) and make chat_session_project idempotent (MUL-3772)

The VCS migrations (#5006) merged concurrently with task_usage_authoritative_cost
and chat_session_project (#5765, renumbered by #5868), colliding on numeric
prefixes 213/214/215. Two problems result:

1. The migration lint (TestMigrationNumericPrefixesStayUniqueAfterLegacySet)
   fails on the duplicate prefixes, so main CI is red.
2. The dev deploy crashes. chat_session_project was first shipped as
   213_chat_session_project, then renamed 213 -> 214 (#5868) to dodge the VCS
   collision. Environments that already applied it as 213 re-run it under the
   new 214 name, and because the ADD COLUMN was not idempotent it fails with
   "column project_id already exists" (SQLSTATE 42701), aborting startup.

Fix:
- Renumber the six VCS migrations off the collisions to a unique contiguous
  tail 216-221, preserving order (table creation at 216 before its indexes at
  217-221). Every VCS migration is CREATE ... IF NOT EXISTS, so re-running them
  under the new names is a safe no-op on any environment that already applied
  the old 213-218 numbers.
- Make 214_chat_session_project idempotent (ADD COLUMN IF NOT EXISTS) so the
  #5868 rename-induced re-run no-ops instead of crashing.

Verified locally: the lint test passes; a fresh `migrate up` applies 213..221 in
order; a DB seeded into the exact dev failure state (project_id column present,
214 version row absent) now re-applies 214 as a no-op and completes; `go build`
and the VCS handler + migration tests pass.

Co-authored-by: multica-agent <github@multica.ai>

server/migrations/214_chat_session_project.up.sql

@@ -4,5 +4,11 @@
 -- Create/delete handlers serialize on the project row, project deletion clears
 -- existing references, and daemon claim revalidates workspace ownership before
 -- injecting any context.
+--
+-- IF NOT EXISTS because this migration was first shipped as 213_chat_session_project
+-- and later renumbered to 214 (#5868, dodging a prefix collision). Environments
+-- that already applied it under the old 213 name have the column but not the 214
+-- version row, so the runner re-applies it under the new name; without the guard
+-- that re-run fails with "column already exists" (SQLSTATE 42701) and blocks deploy.
 ALTER TABLE chat_session
-  ADD COLUMN project_id UUID;
+  ADD COLUMN IF NOT EXISTS project_id UUID;