Investigate whether Studio Pack install needs a DBOS workflow

Context

Studio Pack installation currently runs through a DBOS workflow:

• Better Auth organizationCreation.afterCreate calls seedOrgDb(data.organization.id, data.member.userId) in apps/mesh/src/auth/index.ts.
• seedOrgDb() creates the default well-known physical MCP connections (_self, community registry, Deco Store registry) in apps/mesh/src/auth/org.ts.
• After seeding those connections, seedOrgDb() calls enqueueInstallStudioPack({ orgId, createdBy }).
• enqueueInstallStudioPack() starts the DBOS workflow in apps/mesh/src/auth/install-studio-pack-workflow.ts, which calls installStudioPack().
• App startup also calls backfillStudioPackForAllOrgs() from apps/mesh/src/api/app.ts, which enqueues the same workflow for existing orgs.

Question

Do we actually need DBOS durability for Studio Pack installation, or is this overkill for an idempotent seed/backfill operation?

Why this might be overkill

installStudioPack() appears to be idempotent: it checks whether each well-known virtual MCP already exists before creating it. The workflow currently has deterministic workflow IDs to collapse duplicate enqueues, but a direct idempotent function or a simpler async job may be enough.

The operation is also not clearly user-facing in the same way as long-running durable business workflows. If it fails, the startup backfill already has a repair path.

Things to investigate

• Was DBOS chosen because org creation happens inside Better Auth hooks and should avoid request-time blocking/deadlocks?
• Does installStudioPack() depend on default connections being committed before it runs?
• Are there production incidents or retry requirements that justify DBOS here?
• Can we replace this with a direct post-seed call, a plain background task, or a simpler backfill-safe idempotent helper?
• If DBOS is retained, document why durable workflow semantics are required here.

Acceptance criteria

• Decision recorded: keep DBOS with rationale, or simplify the install path.
• If simplified, existing behavior remains idempotent for new orgs and existing-org backfill.
• Tests continue to cover fresh install and duplicate-install behavior in apps/mesh/src/tools/virtual/studio-pack.integration.test.ts.

Trace the installation path through apps/mesh/src/auth/index.ts, apps/mesh/src/auth/org.ts, apps/mesh/src/auth/install-studio-pack-workflow.ts, and apps/mesh/src/api/app.ts. Read the workflow and seed/backfill behavior first, then run apps/mesh/src/tools/virtual/studio-pack.integration.test.ts for fresh and duplicate installs. Done means recording whether DBOS is retained with rationale or replaced while preserving idempotent new-org and backfill behavior.