🪪 feat: Add Principal-Bound Bridge Workers

[danny-avila]

I added dynamic, principal-bound worker routing on top of secure worker pairing so one Code API deployment can safely dispatch to multiple outbound stateful environments.

• Add a dynamic worker mode that preserves the configured singleton worker as a compatibility default.
• Bind pairing codes and rotated proof-of-possession credentials to a deployment, tenant, user, role, or group principal.
• Carry trusted worker selection across the HTTP, BullMQ, service-worker, and remote-backend boundaries.
• Fence dynamic dispatch by tenant before a Redis assignment or worker lease is created.
• Ignore worker-supplied binding data and persist only the administrator-issued binding.
• Sanitize bridge authorization, availability, capacity, execution, and timeout failures at the public API boundary.
• Document dynamic routing, principal bindings, and the trusted worker-selection header.

Depends on #67.

Change Type

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

Testing

• Ran 79 focused bridge, startup-policy, backend, and public-error tests with Bun.
• Built the service bundle successfully with Rollup.
• Ran a live isolated topology with Code API on 23112, Redis on 26379, two outbound paired workers, and a network-disabled NsJail sandbox on 22000.
• Verified a worker bound to another tenant receives a sanitized 403 before execution.
• Verified two authorized turns reuse one stateful NsJail workspace and read the same persisted file.

Test Configuration:

• Code API: dynamic remote bridge, paired authentication, affinity sessions
• Sandbox: direct NsJail, per-job UIDs, session workspace enabled, networking disabled
• Runtime: Bash 5.2

Checklist

• My code adheres to this projects style guidelines
• I have performed a self-review of my own code
• I have commented in complex areas where the security boundary is not self-evident
• I have made pertinent documentation changes
• My changes do not introduce new warnings
• I have written tests demonstrating that my changes are effective
• Local unit tests pass with my changes
• Any changes dependent on mine have been merged and published in downstream modules

[danny-avila]

@codex review

Please review the exact head commit 34d8268f70e20eaf51f1e9d2fa8c4bc2f6748db0, focusing on tenant fencing, trusted binding provenance, and queue-boundary worker selection.

[danny-avila]

@codex review

Correction: please review the exact head commit 34d8268, focusing on tenant fencing, trusted binding provenance, and queue-boundary worker selection.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	🔄 Running since 2026-08-30T19:52:00.016492Z	44c3507	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 34d82682ed

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[danny-avila]

@codex review

Please review the current PR head 44c3507. Confirm that this exact commit is the reviewed commit and ignore findings that apply only to earlier heads. Focus on authenticated worker selection, queue/replay propagation, pairing supersession, Redis key separation, and credential-bound leasing.