0.16.1: idempotent /chrome onboard + automatic stale-owner takeover

User pain: machines stuck in broken state after pi-chrome upgrades because an old
pi-chrome process kept holding :17318 and /chrome onboard trusted confirm() clicks
without verifying anything. Both fixed.

Idempotent /chrome onboard recovery flow:
- Always resets Pi-side pairing state first (kills half-paired ghosts).
- Step 1 covers both first-install AND v0.15->v0.16 reload (extension service worker
  must reload to gain the /pair logic).
- Actively verifies progress at each step rather than trusting clicks:
  - polls bridge.status().connected (15s window) to confirm the extension polls /next,
  - polls bridge.bridgeAuth.paired to confirm the /pair handshake completed,
  - round-trips a real tab.version command to confirm the signed-envelope path works.
- /chrome install is now an alias of /chrome onboard.

Automatic stale-owner takeover at bridge.start():
- /status now includes bridgeVersion.
- On EADDRINUSE, probe /status with 1s timeout. If unresponsive OR major.minor
  mismatches, locate the owner PID via lsof and kill it (SIGTERM -> SIGKILL),
  then re-bind. Same-version owners are joined as clients (multi-Pi sharing).
- Eliminates the 'stale Pi session holding bridge' class of bugs that broke
  upgrades from 0.15.x.

/chrome status / doctor / onboard no longer hang:
- New probeExtension() short-circuits before bridge.send when the bridge can't
  round-trip (unpaired, or extension hasn't polled recently). Returns immediately
  with an actionable message instead of waiting 5-35s.

0 files changed, 0 insertions, 0 deletions