Per-tenant execution sandboxing

[JSONbored]

Problem: An autonomous, write-capable agent acting on a customer's arbitrary repository is a real attack surface — it must not be able to reach another tenant's data, or gittensory's own infrastructure.

Area: Platform / Security

Proposal: Isolate each customer's loop execution per the tenancy model in #4783, so a compromised or misbehaving run cannot access anything outside its own tenant's scope.

Deliverables:

• A sandboxing mechanism enforced for every loop execution, with no shared execution context between tenants.

Acceptance criteria:

• A deliberately adversarial test run (attempting to access another tenant's data or gittensory's own infrastructure) fails to escape the sandbox.

Boundaries:

• Blocked on Multi-tenant hosted architecture spec #4783. This is a security-critical control — needs its own dedicated review, not just a passing test.

---

Part of #4778.

---

Reconciliation decision (#5669, resolved 2026-07-15): NOT a duplicate of #5222/#4942 -- different surfaces. This issue is Wave 5's product-security control (sandboxing a rented review-loop's execution, per-run isolation); #5222 is AMS's fleet-deployment-asset parameterization (docker-compose/k8s/Terraform) and #4942 is AMS's concurrency-model correctness for a shared datastore. Keep all three open independently; this issue stays blocked on #4783 only (the authoritative tenancy-boundary spec -- see #4783's own resolved cross-reference).

[linear-code]

JSO-3465