Investigate whether Studio Pack install needs a DBOS workflow

[tlgimenes]

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.

[pedrofrxncx]

This is a research/investigation question ("does Studio Pack install need a DBOS workflow"), not yet a scoped code change — there's no fix to attempt until someone with product/architecture context decides the answer. Whoever owns DBOS adoption in this repo should read the current Studio Pack install path and confirm whether it already gets durability guarantees indirectly (e.g. via an existing queue) or is missing them outright. Once that's answered, the actual code change is probably small.