[P1] Coordinate Supabase shutdown with in-flight worker startup

[Keegs12]

Found while auditing Stack #633 (#628–#633).

Problem

SupabasePlatformAdapter.stopWorker() can call worker.stop() while the first HTTP request is still awaiting worker.startOnlyOnce(). The shutdown handler is registered before requests are served, and ensureWorkerStarted() now awaits startup, so an Edge Runtime shutdown can race the initial DB/queue registration.

Worker.stop() immediately calls lifecycle.transitionToStopping(). While startup is pending, WorkerLifecycle is still Created or Starting; neither state permits a transition directly to Stopping. This throws before the worker can drain or be marked stopped. If startup later completes, it can also transition into Running after shutdown was requested.

Affected paths:

• pkgs/edge-worker/src/platform/SupabasePlatformAdapter.ts: shutdown handler → stopWorker()
• pkgs/edge-worker/src/core/Worker.ts: stop() / performStop()

Impact

A function instance shutting down during its first request can reject the shutdown callback, leave the worker startup/DB work unresolved, and fail to update pgflow.workers.stopped_at. This can leave stale worker metadata and complicate task recovery/replacement.

Suggested fix

Make startup and stop share one lifecycle gate: either have Worker.stop() await/cancel startupPromise before transitioning state, or have the adapter retain the startup promise and defer stop until startup settles, with an explicit cancellation/error path. Add a regression test for shutdown during acknowledgeStart() before both Created → Starting and Starting → Running complete.