NetVM: document 1:1 profile:node mapping and launch flow

README.md

@@ -61,20 +61,34 @@ Two ways to get per-node Warp egress were considered:
 Upgrade path if pool IPs prove too fluid: Cloudflare Zero Trust dedicated
 egress (true static IPs, paid).
 
+## Mapping: 1:1 profile = node = warp identity = egress IP
+
+Each chrome-box profile with auth gets its own dedicated Warp
+credentials and its own stable egress IP. The profile name IS the node
+name. One account always on one stable IP is the most human-like
+pattern — it's IP hopping that trips provider alarms.
+
+Interface names are hashed (`wb-<tag>`, `ve-<tag>`) because Linux
+interface names max out at 15 chars; the netns keeps the full
+`warp-<node>` name. See `bin/netvm-names.sh`.
+
 ## Provisioning a node
 
 Identity creation is the human's job; lifecycle is scriptable:
 
-1. Human: run `bin/netvm-new-identity.sh <node>` ON the node — it
-   registers the Warp identity and installs /etc/netvm/<node>.conf
+1. Human: `chrome-box create <profile>` (browser profile).
+2. Human: run `bin/netvm-new-identity.sh <profile>` ON the node — it
+   registers the Warp identity and installs /etc/netvm/<profile>.conf
    (root-owned, 0600). This file is a credential — agents never create,
    read, or copy it, and the script is excluded from the operator sudoers
    allowlist.
-2. sudo bin/netvm-node-up.sh <node> — creates netns warp-<node>, raises
-   the wg interface inside it, verifies egress, prints the result.
-3. chrome-box launches the client's Chromium inside that netns.
+3. Human (or operator over the tailnet): `bin/netvm-chrome.sh <profile> [url]`
+   — ensures the tunnel is up, enters netns `warp-<profile>`, bind-mounts
+   a working resolv.conf (the host's systemd-resolved stub is unreachable
+   in the netns), drops to the invoking user, launches the profile's
+   Chromium. Browser runs as the user, never as root.
 
-Tear down: sudo bin/netvm-node-down.sh <node>.
+Tear down: `bin/netvm-node-down.sh <node>` (sudo).
 
 ## Files