ws bridge: support multiple concurrent bridge instances

[armandokun]

Problem

After fixing the fork-bomb bug (PID lock in ~/.openmail-cli/bridge.lock), the bridge is hard-limited to 1 process per machine. This is the right default, but blocks legitimate use cases:

• Multiple hook endpoints — e.g., forwarding inbox A to one OpenClaw instance and inbox B to another
• Isolated monitoring — running separate bridges per inbox for fault isolation

A single bridge instance already supports multiple inboxes via --inbox-ids a,b,c (or all inboxes when omitted), but everything goes to the same --hook-url.

Proposed solution

Scope the PID lock by instance name so multiple bridges can coexist safely:

# Default (backwards compatible) — lock: bridge.lock
openmail ws bridge

# Named instance — lock: bridge-sales.lock
openmail ws bridge --name sales --inbox-ids inb_xxx --hook-url http://localhost:18789/hooks/sales

# Another named instance — lock: bridge-support.lock
openmail ws bridge --name support --inbox-ids inb_yyy --hook-url http://localhost:18790/hooks/support

Each --name gets its own PID lock file (bridge-{name}.lock) and its own state file (bridge-{name}-state.json). Unnamed instances use the current default paths.

The systemd unit generator (openmail setup) would need to support multiple named service instances, e.g. openmail-bridge@sales.service.

Alternatives considered

• Single process, multiple hook targets — map inbox→hook-url in config. Simpler but less flexible (can't independently restart/monitor).
• Remove PID lock, rely only on server-side connection limit — the server caps at 10 connections per customer, but this doesn't prevent the fork-bomb scenario from the OS side.