Fix Flow key loss after MV3 service worker restart

[Bl0ck154]

What changes

This makes the Manifest V3 background worker hydrate its persisted state on
every worker evaluation, not only after an extension install or a full Chrome
startup. The initialization is shared by lifecycle events so concurrent alarms
or startup events do not open duplicate WebSocket connections.

It also adds a small Node-based regression test for a cold worker start with a
stored Flow bearer token.

Why

MV3 service workers may be suspended and recreated while Chrome itself remains
open. In that path onStartup and onInstalled do not run. The previous code
therefore recreated the local-agent WebSocket while flowKey was still its
module default (null), even though a valid token already existed in
chrome.storage.local. The bridge then reported itself connected but had no
Flow authentication until the Flow tab happened to make another authorized
request.

Validation

node --check extension/background.js

node tests/extension_mv3_bootstrap.test.cjs

The regression test verifies that a cold worker start reads the stored token
before connecting, announces flowKeyPresent: true, forwards the token to the
agent, and does not duplicate initialization when lifecycle events overlap.