chore(enterprise): bump submodule pin — rooms removed from the paid tree (ent#443)

[trinity-ability]

Third and final step of the ent#443 merge order:

1. refactor(rooms): move multi-agent rooms into OSS core (ent#443) #2355 — rooms into OSS core (merged to main, 366cf505)
2. abilityai/trinity-enterprise#444 — module deleted from the paid tree (merged, 2a5def35)
3. this PR — move main's pin onto that commit

Why it can't wait for the release

main.py now imports shared_sessions.router unconditionally, while the pinned enterprise tree at 65182c14 still calls _register_module(app, "shared_sessions"). Until this lands, an entitled build off main mounts rooms twice and advertises an entitlement for a surface every build ships.

The pin moves six commits, not one

main's pin was already behind private tip, so this is not a one-commit hop. Stating it because main is the release branch and this is not a release:

commit	change	reaches main as
39dc7a57	zero-commitment door design (ent#323)	docs-only
9401b755	activation checklist (ent#238)	new module — see below
c5c8ed08	enterprise suite order-independence (ent#379)	tests-only
1dd28bce	room budgets an operator control (ent#387)	inside the tree #444 deleted
a4198127	0007/0008 drop the client_portal import (ent#431)	a fix main was missing
2a5def35	remove shared_sessions (ent#443)	the target

ent#238 is the only one landing new behaviour. Its OSS counterpart (components/onboarding/ActivationChecklist.vue, stores/onboarding.js) is on dev and not on main, so the module registers an endpoint the shipped bundle never calls — inert, not broken. Imports verified against this branch: dependencies.{get_current_user, reject_agent_principal, requires_entitlement}, models.User, and db.tables.{agent_activities, agent_ownership, agent_schedules, audit_log} all resolve. It carries enterprise migration 0016_onboarding_state on the separate enterprise_schema_migrations runner (Invariant #3), so it touches no OSS table.

ent#431 is a fix main currently lacks: at the old pin, enterprise migrations 0007/0008 import a client_portal that ent#356 deleted from the paid tree.

Verification

prod-image-smoke and backend-unit-test are the real arbiters here — they boot the app with the submodule checked out, which is the only thing that proves the two trees agree.

Known follow-up, not introduced here

dev carries Alembic 0039…0043 off the same 0038 parent that #2355's 0044_shared_sessions_oss chains from, so that version line has two heads at reconciliation. check_alembic_heads is required via schema-parity and will block the next release PR loudly; it owes an alembic merge revision at that point. Flagged in #2355's thread; unaffected by this PR.

Refs abilityai/trinity-enterprise#443, abilityai/trinity-enterprise#444

🤖 Generated with Claude Code

https://claude.ai/code/session_01BnrKWx9CRWnSv2LoDgDer7

[vybe]

Correcting a claim in my own PR body before anyone relies on it.

I wrote that "prod-image-smoke and backend-unit-test are the real arbiters here — they boot the app with the submodule checked out." They do not. Neither backend-unit-test.yml nor backend-image-smoke.yml checks out src/backend/enterprise at all — there is no submodules: key in either, which is exactly why build-without-submodule.yml exists as a separate job.

So no CI in this repo validates the pin. Green here means "the OSS tree is fine", not "the OSS tree and the pinned enterprise tree agree".

What actually covers it, and what does not:

• The private repo's enterprise-tests.yml checks out Abilityai/trinity at ref: dev — not main. So trinity-enterprise#444 was verified against dev, and this pin lands on main.
• The gap that leaves is exactly the ent#238 activation-checklist module, whose OSS counterpart is on dev and not on main. I checked its imports against this branch by hand rather than by CI — dependencies.{get_current_user, reject_agent_principal, requires_entitlement}, models.User, db.tables.{agent_activities, agent_ownership, agent_schedules, audit_log} all resolve on main — and its migration is on the separate enterprise_schema_migrations runner, so it touches no OSS table.
• Manual import check by hand is weaker evidence than a boot. Worth a /verify-local with the submodule mounted before this is relied on in production, and worth considering whether enterprise-tests.yml should matrix dev and main — a paid module can only be proven against the branch it will actually ship on, and today nothing tests the released one.

[vybe]

Validated the pin locally, since I established above that no CI here does.

Materialised the pinned enterprise tree (2a5def35) inside a worktree of this branch — i.e. main + #2355 + this pin — and checked it against the OSS tree it will actually run on.

1. The double-mount this PR exists to close is closed.

$ grep -n '_register_module' src/backend/enterprise/backend/__init__.py
  ... user_management, siem, retention, portal_session_policy, two_factor, sso,
      permissions_matrix, ephemeral_agents, telemetry, skill_runner,
      slack_per_agent_bots, cross_model_validation, compliance_export, a2a, onboarding

No shared_sessions entry. backend/shared_sessions/ is absent from the enterprise tree and present in the OSS tree — the two halves agree, and an entitled build off main now mounts rooms exactly once.

2. Every enterprise→OSS import resolves on main. This is the ent#238 concern, and it is the one thing a pin bump can break silently:

enterprise -> OSS module-scope imports checked: 173
UNRESOLVED MODULES: none

And at symbol level for the two files that carry the new module:

OK  onboarding/router.py: from dependencies import get_current_user
OK  onboarding/router.py: from dependencies import reject_agent_principal
OK  onboarding/router.py: from dependencies import requires_entitlement
OK  onboarding/router.py: from models import User
OK  _activation.py:       from db.tables import agent_activities
OK  _activation.py:       from db.tables import agent_ownership
OK  _activation.py:       from db.tables import agent_schedules
OK  _activation.py:       from db.tables import audit_log

What this does and does not prove. It proves the import graph closes — the ModuleNotFoundError-at-boot class (#1033 / ent#356 / ent#443) cannot fire from this pin. It does not prove the app boots: it is static resolution, not an import, and it does not exercise the enterprise migration runner (0016_onboarding_state on enterprise_schema_migrations). A /verify-local with the submodule mounted is still the stronger check before this is leaned on in production.

The residual is unchanged and stated in the body: ent#238 registers an endpoint main's shipped bundle never calls, because its OSS counterpart is on dev. Inert, not broken.

[vybe]

Approving on the local validation posted above, since — as established in the same comment — no CI in this repo checks out the submodule, so green here says nothing about the pin itself.

What was verified by hand against a worktree of this branch with the pinned tree materialised:

• The double-mount is closed. No _register_module(app, "shared_sessions") in the enterprise tree at 2a5def35; backend/shared_sessions/ absent there and src/backend/shared_sessions/ present in OSS. The two halves agree.
• 173 enterprise→OSS module-scope imports resolve on main, none unresolved, plus symbol-level checks on the eight names the new ent#238 module needs.

Scope of that evidence, stated plainly: it rules out the ModuleNotFoundError-at-boot class (#1033 / ent#356 / ent#443) and nothing more. It is static resolution, not an import, and it does not exercise the enterprise migration runner. A /verify-local with the submodule mounted remains the stronger check.

Pin confirmed still at 2a5def35 at merge time — deliberately two commits behind private tip, not stale: ff0a4f15 (ent#435 enterprise half) must not reach main before its OSS counterpart #2330, which is on dev, and 6d82a3fa is docs-only.