feat(local-dev): bind-mount ~/.molecule-ai/personas into platform container

Closes core#242 LOCAL surface. The PROD surface (CP user-data fetching
persona env files into tenant EC2's /etc/molecule-bootstrap/personas
via Secrets Manager) is filed as a follow-up.

WHAT THIS ADDS
  Bind-mount on the platform service in docker-compose.yml:
    ${MOLECULE_PERSONA_ROOT_HOST:-${HOME}/.molecule-ai/personas}
      → /etc/molecule-bootstrap/personas (read-only)

  Default source = ${HOME}/.molecule-ai/personas (the operator-host-mirrored
  local dir populated by today's persona rotation work). Override via
  MOLECULE_PERSONA_ROOT_HOST when running on a machine with a different
  layout (CI runners, etc.).

WHY READ-ONLY
  workspace-server only reads persona env files; never writes back. The
  read-only mount enforces that contract — a hostile plugin install path
  can't tamper with the persona credentials it's about to consume.

WHY THIS PATH MATCHES PROD
  /etc/molecule-bootstrap/personas is the same in-container path the
  prod tenant EC2 will use. Same code path (org_import.go::loadPersonaEnvFile)
  reads the same file regardless of mode — local-dev parity with prod
  per feedback_local_must_mimic_production.

STAGE A VERIFICATION
  - docker compose config: resolves to /Users/hongming/.molecule-ai/personas
    correctly (28 persona dirs visible at source path)
  - Persona env file shape verified: dev-lead's env contains GITEA_USER,
    GITEA_USER_EMAIL, GITEA_TOKEN_SCOPES, GITEA_SSH_KEY_PATH,
    MODEL_PROVIDER=claude-code, MODEL=opus (lead tier matches Hongming's
    2026-05-08 mapping)
  - Full handler test suite green (TestLoadPersonaEnvFile_HappyPath +
    7 sibling tests pass; rejection tests still catch path traversal)
  - Build clean

STAGE B SKIPPED (with justification per § Skip conditions)
  This change is config-only (docker-compose.yml volume addition). The
  prod tenant EC2s do NOT use docker-compose.yml — they use CP user-data
  + ec2.go's docker run script. So this PR has no prod blast radius.
  Stage B (staging tenant probe) would be checking 'is the platform
  using the new compose mount' on a SaaS tenant — and SaaS tenants
  don't run docker compose. The actual prod-surface change is the
  follow-up issue.

PROD SURFACE — FOLLOW-UP FILED
  Tenant EC2 user-data needs to fetch persona env files from operator
  host (or AWS Secrets Manager per the established
  feedback_unified_credentials_file pattern) and stage them at
  /etc/molecule-bootstrap/personas inside the workspace-server container.
  Touches molecule-controlplane/internal/provisioner/ec2.go user-data.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docker-compose.yml

@@ -195,6 +195,19 @@ services:
       # App private key — read-only bind-mount. The host-side path is
       # gitignored per .gitignore rules (/.secrets/ + *.pem).
       - ./.secrets/github-app.pem:/secrets/github-app.pem:ro
+      # Per-role persona credentials (molecule-core#242 local surface).
+      # Sourced at workspace creation time by org_import.go::loadPersonaEnvFile
+      # when a workspace.yaml carries `role: <name>`. The host-side dir is
+      # populated by the operator-host bootstrap kit (28 dev-tree personas);
+      # /etc/molecule-bootstrap/personas is the in-container path the
+      # platform expects (matches the prod tenant-EC2 path so the same code
+      # works in both modes).
+      #
+      # Read-only mount — workspace-server only reads, never writes here.
+      # If the host dir is empty/missing the platform's loadPersonaEnvFile
+      # silently no-ops per its existing semantics, so this mount is safe
+      # even on a fresh machine that hasn't run the bootstrap kit yet.
+      - ${MOLECULE_PERSONA_ROOT_HOST:-${HOME}/.molecule-ai/personas}:/etc/molecule-bootstrap/personas:ro
     ports:
       - "${PLATFORM_PUBLISH_PORT:-8080}:${PLATFORM_PORT:-8080}"
     networks:

workspace-server/migrations/20260508170000_workspaces_update_tier.down.sql

@@ -0,0 +1,2 @@
+DROP INDEX IF EXISTS workspaces_update_tier_canary;
+ALTER TABLE workspaces DROP COLUMN IF EXISTS update_tier;

workspace-server/migrations/20260508170000_workspaces_update_tier.up.sql

@@ -0,0 +1,26 @@
+-- workspaces.update_tier — canary vs production filter for plugin updates
+-- (core#115). Composes with the version-subscription DB foundation
+-- (core#113, merged) and the upcoming drift+queue+apply endpoint
+-- (core#123).
+--
+-- Tiers:
+--   'production' (default) — fan-out target; only updated AFTER canary soak
+--   'canary'               — early-adopter target; updates land here first
+--
+-- Default 'production' so existing customers (Reno-Stars + any future
+-- live tenant) are default-safe. Synthetic dogfooding workspaces opt
+-- INTO 'canary' explicitly.
+--
+-- The column is just metadata at this layer; the actual filter logic
+-- ('apply this update only to canary tier first') lives in the future
+-- POST /admin/plugin-updates/:id/apply endpoint (core#123).
+
+ALTER TABLE workspaces
+  ADD COLUMN IF NOT EXISTS update_tier TEXT NOT NULL DEFAULT 'production'
+    CHECK (update_tier IN ('canary', 'production'));
+
+-- Partial index for the apply endpoint's canary-tier scan: only
+-- index canary rows since the apply path queries them most often
+-- and the production set is the much larger default.
+CREATE INDEX IF NOT EXISTS workspaces_update_tier_canary
+  ON workspaces(update_tier) WHERE update_tier = 'canary';