Local browser access to /ide/ on Tower: bootstrap the forward credential for a loopback browser and add an Open IDE link per workspace #1869

Problem

After afx ide install && afx ide start on a local machine, the natural next step is to open http://localhost:4100/ide/?folder=<path> in a browser. Tower answers 401. Trying the server directly at http://127.0.0.1:8200/ide/ answers 403. The only working entries today are the Codev Cloud URL (needs an owner session and a tunnel round trip) or a hand-built http://127.0.0.1:8200/ide/?tkn=<token>&folder=…, which is not a user path.

Measured 2026-10-29 on macOS with codev 3.3.6 and @cluesmith/codev-ide 1.0.0:

GET http://127.0.0.1:4100/ide/                          -> 401  (bare browser navigation)
GET http://127.0.0.1:8200/ide/                          -> 403  (server wants its connection token)
GET http://127.0.0.1:4100/ide/?folder=…  + codev-tower-key header -> 200 text/html

Root cause

Tower's HTTP choke point (isRequestAllowed, server-utils.ts) accepts the local key only as a request header (codev-tower-key, legacy codev-web-key). The dashboard works because GET / is a public route whose HTML gets the key injected as window.__CODEV_TOWER_KEY__, and every dashboard fetch then adds the header. A top-level browser navigation to /ide/ cannot carry a header, so it never reaches the forward. The cloud path works only because the tunnel proxy stamps the header server-side on every request.

The IDE connection token is not the gap: ide-forward.ts already injects the vscode-tkn cookie on every forwarded request, cloud or local. The gap is that a local browser has no header-free way to present the Tower key, and this applies not just to the first navigation but to every workbench asset request and every ?reconnectionToken= WebSocket the workbench opens against 4100/ide/….

Proposed rule

Give a local browser a header-free credential for the /ide/ prefix that carries the same trust as the key header, without weakening either secret:

• An authenticated dashboard action (fetch with the key header) mints a session credential for the forward, delivered as an HttpOnly; SameSite=Strict; Path=/ide cookie (or sets the key itself in such a cookie). Only the Host-guarded loopback origin can obtain it, and only by already holding the key.
• isForwardAuthorized (the one authorization seam for the forward, HTTP and WebSocket upgrade alike) accepts that cookie as an alternative to the header. isRequestAllowed lets /ide/* through to that seam when the cookie is present. Nothing else in Tower accepts the cookie.
• Add an Open IDE link per workspace on the local dashboard that performs the mint and then opens /ide/?folder=<workspace path> in a new tab. This is the local counterpart of the cloud dashboard's Open IDE entry.

Non-goals: do not drop the server's connection token (upstream VS Code requires it on localhost for good reason); do not open /ide/ to bare loopback requests that hold neither the header nor the minted cookie; the cloud path is unchanged.

Acceptance

• On a machine with Tower and the IDE server running, the local dashboard shows an Open IDE link per workspace that opens the workbench with the Codev sidebar in a new tab, with no cloud session and no hand-built URL. The workbench's assets and its WebSocket connections all succeed through 4100/ide/.
• A bare curl http://127.0.0.1:4100/ide/ still returns 401. A request with a rebound Host still fails the Host guard.
• The cloud URL still works unchanged.
• codev/resources/commands/agent-farm.md (and the skeleton twin) describe the Open IDE link and the local URL as the user path.

Reported by the codev-ide workspace architect from the owner's first local use of 3.3.6 + codev-ide 1.0.0. Related: #1668 (IDE prefix forward), #1789 (Tower-managed server), #1589 (per-session remote credential, the planned swap point in isForwardAuthorized).