Reverse loopback forwarding: let the guest reach host-bound localhost services (e.g. JetBrains Claude Code plugin)

[karudo]

clawk forward add solves guest→host exposure (a dev server in the VM becomes reachable
on the host's localhost). There's no equivalent in the other direction: a service bound to
127.0.0.1 on the host is not reachable from inside the guest, even if its hostname/IP
were added via clawk network allow.

This matters for tools that expect the agent process and the local IDE tooling to share a
loopback address. Concrete example: the Claude Code plugin for JetBrains IDEs discovers a
running claude CLI process via a lock file in ~/.claude/ide/, which stores a port that
the plugin's local websocket server listens on at 127.0.0.1:<port>. This is how the plugin
provides diff-viewing, selection-context sharing, and the /ide quick-connect flow.

When claude runs inside a clawk sandbox instead of natively on the host:

• ~/.claude/ide/ isn't part of the host-mounted state (only ~/.claude/projects/ and
  ~/.claude/memory/ are), so the guest's claude can't discover the lock file at all.
• Even if it could, 127.0.0.1 inside the guest resolves to the guest's own loopback
  (separate netns / vsock-based network stack), not the host's — so the connection back to
  the plugin's local server has no path, allow-listed or not.

Net effect: Claude Code running under clawk can't hook into the JetBrains plugin's IDE
features at all today. Users have to choose between the sandbox (clawk) and the IDE
integration (native claude in the terminal), not both.

Proposed solution

A reverse counterpart to clawk forward add — something like:

clawk forward add-reverse my-project 12345   # host 127.0.0.1:12345 -> reachable inside guest

exposing a chosen host loopback port to the guest (presumably via a dedicated address on the
gvproxy-side gateway, so it doesn't require rewriting 127.0.0.1 semantics guest-side).
Combined with optionally sharing ~/.claude/ide/ as read-only guest state (or letting users
add it via shares (...) in clawk.mod), this would let the guest-side claude discover
and connect to a host-bound IDE plugin like any locally-running instance would.

Alternatives considered

• Just don't use the plugin's IDE panel; run clawk attach in the IDE's terminal tab instead
  and rely on the IDE's normal file-watching/VCS view for diffs (works today, since the
  worktree is live-mounted, but loses selection-context sharing and the plugin's UI).
• Fully proxy the vsock control channel through to a host-side claude process instead —
  bigger change, probably out of scope for this specific request.

Happy to test against a WebStorm + Claude Code plugin setup if useful.