bridges: give each concurrent process its own Machine slot

[guygrigsby]

Parallel aperture sessions in bridge mode evicted each other (APT-330). Every process opened the same state directory for a bridge, so every process registered the same node key, and the control plane handed the session to the newest registrant. The older processes showed Running locally while their dials reached nothing, which surfaced as hangs and "api error". The shared directory was also being written concurrently.

This PR numbers a bridge's Machine identity by slot. Slot 1 keeps the existing state directory and hostname, so devices users already authorized carry over. Slots 2 and up get suffixed siblings: bridges/<hex>-N on disk and aperture-cli-<bridgeID>-N in the admin console. A process claims the lowest free slot when it builds the node and holds it until the Machine closes or is destroyed. The claim is an exclusive non-blocking lock on bridges/locks/<hex>-<slot>.lock, flock on unix and LockFileEx on Windows. Locks live outside the state directory so removal never deletes an open lock.

Machines.Destroy now logs out every slot the bridge has on disk. It refuses, before any logout, when another live process holds a slot and names the conflict. The removal screens list every device the bridge registered, the way the admin console shows them.

TS_AUTHKEY, when set, authorizes a fresh slot without the browser login. Once a slot has registered, its state directory carries the credentials and the key is not consulted again for it. The README gains a section on concurrent sessions and a table of every environment variable the launcher reads. ADR 0006 records the decision and why a shared daemon and ephemeral per-process nodes were rejected.

Risks:

• Each concurrent process is its own device in the admin console. Ten parallel sessions are ten devices. A process that dies without closing leaves its device listed offline until the bridge is removed.
• Every new slot needs one browser login unless TS_AUTHKEY is set. Agent fleets need a reusable key or each slot asks once. The key decides which tailnet the fresh device joins, so a key from the wrong tailnet registers the device there.
• Removing a bridge fails while another aperture process has it open. That case used to log the live session out silently, so this is the intended trade, but it is a new error users will see.
• A Destroy that returns at its deadline while the node's Close hangs keeps slot 1 locked until the close finishes. A reopen in that window takes slot 2, a fresh device and a fresh login, where it used to wait on the stuck close.
• Slots are capped at 100 per bridge. Past that the process errors rather than probing further.