refactor(workspace)!: replace App and add Workspace API keys

[Yevanchen]

Parent

• feat(platform): pivot Mosoo to an API-first managed Agent runtime #546

What to build

Replace App with Workspace as Mosoo's user-facing tenant and resource-ownership concept, then introduce a Workspace-scoped API key as the credential for programmatic execution.

This is a one-to-one semantic migration, not a new hierarchy:

• Each existing App becomes one Workspace with the same identity, name, organization, owner, resources, and history.
• The existing Organization relationship remains unchanged. Membership, billing, and organization redesign are outside this slice.
• Rename the concept end to end across the console, navigation, switcher, onboarding, settings, routes, API and GraphQL contracts, identifiers, authorization context, resource ownership, analytics dimensions, errors, generated clients, SDK/CLI behavior, documentation, examples, and translations.
• Agents, Sessions, Runs, Environments, Skills, files, MCP connections, provider credentials, usage, and audit records become Workspace-owned without changing their actual owner or losing history.
• Do not leave a permanent App/Workspace dual model, aliases, compatibility types, duplicate routes, or dual-read/dual-write code. Temporary expand/backfill/cutover code is acceptable only during migration and must be removed before this issue closes.

Add Workspace API keys with the OpenRouter-like developer experience:

• A key belongs to exactly one Workspace and grants no ambient access to another Workspace, even when the same account owns both.
• An authorized Workspace user can create, list, rotate, and revoke keys from Workspace settings.
• The secret is displayed once, stored only as a hash, never returned by list operations, and never written to logs, events, analytics, snapshots, or artifacts.
• Key metadata includes a label, creation and revocation state, and last-used information.
• Public API authentication resolves the Workspace directly from the key. Authorization for every Agent, Session, Environment, Resource, file, credential, and secret fails closed outside that Workspace.
• Rate limiting, idempotency, usage attribution, and audit records use Workspace and key identity rather than the key creator's account-wide identity.
• Use the standard bearer-header integration shape in API documentation and SDK examples.

Account personal access tokens must not be silently reinterpreted as Workspace keys because one account may own multiple Workspaces. At completion, the public execution data plane accepts Workspace keys, not account-wide personal tokens. Account tokens may remain only for explicitly documented interactive control-plane or CLI user authentication and must not authorize Workspace execution.

Update the CLI and SDK contract so that programmatic execution uses a Workspace key, the active Workspace is explicit, and App-named commands, flags, configuration, output, and documentation are removed. If a shipped CLI is maintained outside this repository, its compatible release and smoke verification remain part of the acceptance boundary.

Migrate production data through an append-only, verifiable sequence:

1. Inventory every App and App-owned resource.
2. Add the Workspace storage and ownership contract.
3. Backfill each App to exactly one Workspace while preserving identifiers and relationships.
4. Verify row counts, ownership, and orphan checks for every resource family.
5. Cut API, web, SDK, and CLI callers to Workspace semantics.
6. Remove temporary migration code and the active App model.

Do not rewrite historical migration files, snapshots, or journals. Any destructive table or column rewrite requires explicit approval, a production backup, verification queries, a rollback plan, and a cutover checkpoint before the contract phase.

Acceptance criteria

• Existing users see the same tenant, resources, and history under Workspace without manually recreating anything.
• A user can create or switch Workspace, create a Workspace API key, and make a successful authenticated public API call against a resource in that Workspace.
• A key for Workspace A cannot read, start, continue, cancel, or retrieve artifacts from Workspace B, including when one account owns both.
• Revoking a Workspace key immediately prevents subsequent API admission.
• Key plaintext is shown once and is absent from storage, logs, events, analytics, snapshots, and artifacts.
• Idempotency, rate limiting, usage, and audit attribution distinguish Workspace and key identity correctly.
• Public execution endpoints no longer accept account-wide personal access tokens.
• Console, API, GraphQL, contracts, generated clients, analytics, SDK, CLI, documentation, examples, errors, and translations use Workspace terminology consistently.
• No active App type, route, ownership field, compatibility alias, or dual-read/dual-write path remains after cutover.
• Every pre-migration App maps to exactly one Workspace with unchanged resource ownership and no orphaned Agents, Sessions, Runs, Environments, files, credentials, usage, or audit records.
• Fresh migration-chain replay and production-shaped forward migration both pass, with before/after verification evidence attached.
• Frontend, API, authorization, key-security, SDK/CLI, database, and end-to-end tests pass.
• Billing implementation is not introduced by this slice.

Blocked by

• refactor(deployment)!: remove App Deployment and bound capabilities #580 — remove App Deployment and its App-scoped authority model before renaming the remaining tenant boundary.
• refactor(channels)!: remove Channels from Mosoo end to end #579 transitively through the required execution order.