fix(serve): align same-host daemon text reads with CLI permissions #8618

Problem

In qwen serve, ACP currently advertises client-side text reads. The production bridge routes those requests through the workspace filesystem boundary, so a direct read_file call for a host text file outside the registered workspace is rejected even after the normal tool permission flow approves it. The model may then retry through the shell, which is both confusing and inconsistent with regular same-host CLI behavior.

Root cause

The bridge uses the same ACP filesystem capability for generic, remote, IDE, and same-host daemon deployments. That compatibility default is correct for remote or virtual filesystems, but it forces same-host daemon children to delegate every FileSystemService.readTextFile consumer to the workspace-bound client.

Proposed behavior

Add an optional bridge setting that controls whether ACP text reads are delegated to the client. Keep delegation enabled by default, but disable it for daemon-owned same-host runtimes while leaving text writes delegated.

For same-host qwen serve runtimes, the ACP handshake should therefore advertise:

{
  "readTextFile": false,
  "writeTextFile": true
}

This lets the child use its regular CLI filesystem service for text reads. External direct read_file calls continue to use normal CLI permission rules: default confirmation, denial without content disclosure, and automatic execution under allow rules or YOLO. Final ACP writeTextFile content writes and HTTP filesystem routes remain protected by the workspace filesystem.

Security and compatibility boundary

• Generic ACP, IDE, remote, and virtual-filesystem consumers must retain delegated reads by default.
• The setting affects every FileSystemService.readTextFile consumer, including shared pre-reads for write, edit, notebook, sed, and artifact operations.
• Child-local reads no longer receive the workspace filesystem read cap, read audit, symlink rejection, or read-side TOCTOU protections.
• qwen serve remains a same-machine, same-UID, single-security-principal runtime, not an OS sandbox.
• Caller-injected bridges retain caller ownership.
• Final ACP text writes continue through the workspace filesystem with trust, symlink, atomic-write, and audit enforcement.

Acceptance criteria

• The bridge defaults to { readTextFile: true, writeTextFile: true }.
• Daemon-owned default, primary, static-secondary, and dynamic workspace bridges advertise { readTextFile: false, writeTextFile: true }.
• With default approval mode, approving an external text read_file returns the content to the model; rejecting it never returns the content.
• HTTP external reads and external, untrusted, or symlinked ACP writes remain workspace-filesystem rejected.
• Tests cover capability negotiation, asymmetric read/write routing, all daemon wiring points, and a deterministic real-daemon approve/reject flow.