#20197: twenty CLI: detect expired token on deploy/dev and offer interactive re-auth

Context

After a local DB reset (a routine action during dev — clears core.appToken), twenty deploy and twenty dev fail with:

Upload failed: Token has expired.

The error is technically accurate but doesn't help: the user has to know to re-run twenty remote add --local --api-key <NEW_KEY> with a freshly-minted key from Settings → Developers. This came up while testing PR #20181 (generic OAuth provider for apps) and is independent of that work — same friction hits any DB reset, key revocation, or workspace deletion.

Proposal

Two changes to the same code path (packages/twenty-sdk/src/cli/operations/deploy.ts and dev.ts, plus ApiService.uploadAppTarball):

(1) Better error message + remediation hint

When apiService.uploadAppTarball returns 401 / a token-expired error, replace the generic \"Upload failed: Token has expired.\" with something like:

Your API key for remote \"local\" is no longer valid (the workspace may have been
reset, or the key was revoked).

Re-authenticate with:
  twenty remote add --local --api-key <NEW_KEY>

Generate a new key at: <SERVER_URL>/settings/developers

5-minute change. Stops the user from googling.

(2) Interactive re-auth prompt

When detection fires AND the process is attached to a TTY, prompt:

Re-authenticate now? [Y/n]

If yes, drop into the same flow that twenty remote add already uses (packages/twenty-sdk/src/cli/commands/remote.ts — authenticate(...)), rewrite ~/.twenty/config.json for the active remote, then retry the original deploy / dev operation transparently. Skip the prompt in non-TTY contexts (CI) and just exit with the message from (1).

This is the pattern gh auth login, vercel, and gcloud use — detect 401, surface the exact command, optionally run it inline.

Out of scope

• Long-lived dev tokens for --local remotes — orthogonal (helps natural expiry, not DB reset). File separately if it becomes a complaint.
• Web-based OAuth login flow for the CLI — bigger lift; the current API-key flow is fine if (2) makes it painless.

Acceptance

• After a DB reset, running twenty deploy (or twenty dev) prints the remediation hint and (in a TTY) offers to re-auth and retry.
• In CI, behavior is unchanged: clear error, exit non-zero, no prompt.