Remote-control bridge sessions track 'parked' vs 'live' project-thread status

What

• The bridge loop now distinguishes project-thread-bound sessions more explicitly: session-done telemetry (tengu_bridge_session_done) gains a project_thread field, session-start telemetry gains rc_child/project_thread/resumed_turn fields, and shutdown persistence separately tracks "parked" vs "live" project-thread session IDs (parkedProjectThreadSessionIds) so they can be remembered across restarts.
• Starting a headless bridge session now emits a tengu_bridge_started event with max_sessions, sandbox, spawn_mode, heartbeat_interval_ms, and headless fields, and requeuing project-thread sessions on startup emits a new tengu_bridge_project_thread_requeue event with requested/requeued/dropped/deferred/unattempted counts.
• The function deciding whether to resume a project thread now checks both the live projectThreadSessionIds and the new parkedProjectThreadSessionIds set (each with its own persisted-at timestamp), resuming if either is populated.

Why

This lets remote-control sessions survive restarts more reliably by remembering project-thread sessions that were parked rather than actively running, and gives clearer telemetry for diagnosing bridge/session behavior.