Route production host access through Env #156

Purpose

Keep executable code portable by making host behavior an explicit contextual capability rather than accessing Deno or Node globals at call sites.

Scope

• Survey production uses of Deno and node:process, starting with CLI worker relaunch, permission prompts, and the test-agent ACP server.
• Design API.Env around the consumer operations those call sites need; do not mirror Deno or Node APIs by default.
• Install runtime- or executable-specific behavior with dedicated Env.around middleware. The resolver should use process.execPath where that is the right cross-runtime primitive; Deno supports the Node process compatibility API.
• Migrate production call sites to the resulting Env capabilities, leaving the designated default Env adapter as the only host-specific boundary.
• Add an AGENTS.md rule: production code must not access Deno- or Node-specific APIs directly; access host behavior through environments.
• Add a repository Oxlint rule that rejects direct Deno globals and node:process imports in production source outside the designated Env adapter modules. Start with production source only; tests and scripts are out of scope.

Acceptance criteria

• Production consumer modules no longer access Deno or node:process directly except in approved Env adapter modules.
• The lint rule catches new prohibited production uses and has rule tests.
• Existing Deno source, compiled binary, and npm/Node CLI worker-relaunch paths remain covered.
• The architecture and lint boundary are documented in AGENTS.md.

Context

The immediate 0.5.1 repair may temporarily use node:process in the CLI resolver to restore npm publishing. This issue owns the subsequent architectural cleanup and enforcement; it should not delay that release repair.