CLI admin commands can fail after upgrade when DB exists but migrations have not been applied

[rishabhpoddar]

Summary

Admin CLI commands such as create-user, delete-user, change-user-role, reset-password, and rotate-jwt-secret currently skip prisma migrate deploy whenever the workspace SQLite file already exists. This avoids lock contention against a running server, but it also creates an upgrade gap: after installing a newer TeamCopilot version with pending migrations, these commands can fail with Prisma schema/runtime errors unless the user has run start once first.

Current behavior

• bootstrapCliDatabaseAccess() only runs ensureWorkspaceDatabase() when the DB file is missing.
• If the DB file exists but the schema is outdated for the installed package version, admin CLI commands go straight to Prisma queries.
• Prisma can then error because the local database schema no longer matches the generated client / expected schema.

Why this matters

This is a bad upgrade experience for npm users because admin commands appear supported through npx teamcopilot <command>, but after upgrading they may fail until npx teamcopilot start has been run at least once.

Repro

1. Initialize and start an older version so the workspace DB exists.
2. Upgrade to a newer package version containing a new Prisma migration.
3. Run npx teamcopilot create-user without running npx teamcopilot start first.
4. Observe Prisma/db schema mismatch failure.

Possible fixes

• Detect pending migrations or schema version mismatch in CLI bootstrap and return a clear error telling the user to run npx teamcopilot start first.
• Or implement a safe migration strategy for non-server CLI commands that does not contend with a running server.

Acceptance criteria

• Admin CLI commands do not fail with opaque Prisma schema errors after package upgrade.
• Users either get a safe auto-remediation path or a clear explicit instruction to run start first.