Give forked backend workers distinct socket-owner identities
When an app is imported before a production server forks, every worker inherits the same token-manager instance ID. A worker receiving a backend-initiated delta then mistakes another worker's live socket record for its own stale record and drops the update.
Assign a fresh socket-owner identity at event-processor startup, after the fork and before events are processed. The change adds no per-event PID checks or allocations. Addresses prerelease finding 003; the defect is verified on the forked-worker path and is pre-existing.
Validation:
- A new test forks the already-created app into two workers. Before the fix it fails because publishing the remote delta returns false; afterward both workers have distinct IDs and publish the expected payload to the owner's channel.
- A separate probe using two forked processes and a temporary real Redis server delivered all six backend-initiated updates through
EventNamespace.emit_update, with different parent/owner/sender identities. All probe processes were stopped. - App, token-manager, shared-state, and lifespan suites: 201 passed, 5 skipped. Ruff checks pass.
Reviewed the startup ordering, stable identity during event processing, and preservation of stale-local-socket rejection. This is independent of the production preload optimization in #7079, which makes the same lifecycle boundary particularly relevant.