Track upstream microsandbox first-secret TLS activation bug

[onsails]

Summary

Track the temporary Right Agent workaround for superradcompany/microsandbox#1422.

microsandbox 0.6.10 persists the first secret added through modify().secret(...).restart().apply() but leaves TLS interception disabled. Provider placeholders then reach upstream APIs without substitution.

Production impact

This broke provider migration/rotation for agents whose sandbox was created before credentials were re-entered:

• TwitterAPI.IO returned authentication failures although the stored key was valid.
• FAL appeared unset after dashboard rotation.
• Sandbox inspection showed correct bindings and allowed hosts, but network.tls.enabled=false.

Live recovery confirmed:

• stored Twitter and FAL values matched operator-supplied files without exposing the values;
• TLS-enabled sandbox requests returned HTTP 200 for TwitterAPI.IO and FAL;
• the riskoff sandbox data fingerprint was preserved through the recovery cutover;
• riskoff-bot, MCP server, cloudflared, and Claude startup health were all healthy afterward.

Right Agent work

• Vendor microsandbox 0.6.10 with a minimal patch in apply_secret_patch_to_config() that enables TLS when the resulting secret set is non-empty.
• Keep dashboard rotation propagation and startup reconciliation tests.
• Add real-microVM regression coverage for:
  • first secret added to an existing TLS-disabled sandbox;
  • TLS enabled in durable and active config;
  • placeholder remains guest-visible;
  • HTTPS substitution reaches a local TLS fixture;
  • second independent provider binding;
  • live value rotation;
  • filesystem sentinel survives restart-backed changes.

Exit criteria

• Upstream releases a version containing the fix and equivalent regression coverage.
• Right Agent upgrades the pinned microsandbox version.
• Remove vendor/microsandbox and restore the registry dependency.
• Full workspace and live provider contract tests pass against upstream.

[onsails]

Status check 2026-08-24 (part of #201 bookkeeping): upstream superradcompany/microsandbox#1422 still OPEN — no fix shipped, only a volunteer comment. Our workaround remains in place and correct on the pinned SDK 0.6.10:

• Existing bindings: SandboxHandle::apply_secret (shrink→rotate→widen).
• Missing binding on a NeedsValue-created sandbox: modify().secret(...).restart().apply() — the stop/persist/start cycle enables TLS interception for the first secret (the exact gap #1422 describes), preserving the writable filesystem.
• Final removal persists TLS-off in desired config; the running VM keeps TLS-on-but-credential-free until next start (no live TLS toggle in 0.6.10).

No action needed on our side; keeping this open as the upstream tracker until 1422 lands and we can drop the restart path for the first-secret case. See docs/architecture/providers.md 'Placeholder substitution'.