feat(workers): report a failed worker creation separately from a failed module

[johnstonmatt]

Stacked on #743. Same shape, for worker creation rather than cancellation.

InvalidWorkerCreation covers three unrelated outcomes and only the last is the caller's own code failing:

Site	Cause	Now reports
ext/workers/lib.rs:305	the pool dropped the sender	WorkerUnavailable
ext/workers/lib.rs:314 via pool.rs:379	worker did not come up in time	WorkerUnavailable
ext/workers/lib.rs:314 via worker_inner.rs:250	module threw while being evaluated	InvalidWorkerCreation

The first two mean no worker was produced, so the module was never evaluated and nothing about it could have caused the failure. They share a name because they classify identically; the message still distinguishes them.

The pool now sends a typed WorkerCreationTimeout rather than anyhow!("worker did not respond in time"), so the second case is matchable instead of only being distinguishable by its text.

Notes for review

• InvalidWorkerCreation narrows in meaning. It previously covered all three; it now means only that evaluating the module failed. Anything keying on it for the platform cases will stop seeing them.
• The request-path match lists WorkerCreationTimeout explicitly and maps it to InvalidWorkerResponse, rather than widening to a wildcard. It cannot occur there, but listing it keeps the compiler forcing a decision when the next variant is added — which is how this change got caught in the first place.
• Two integration tests asserted InvalidWorkerCreation: worker did not respond in time and now expect WorkerUnavailable. The worker boot error assertions are deliberately untouched, since that case keeps its name.

Verification

cargo check clean for ext_workers. The base crate does not build in my environment (its build script links openblas, not installed), so pool.rs and the integration test updates need CI.

Consumers need updating first

InvalidWorkerCreation narrows here rather than staying put, so this is a breaking change for anything that maps it. Two of the three cases it used to cover now arrive as WorkerUnavailable, which an existing embedder will not recognise, and those requests will fall through to its unhandled-error path.

So the ordering is: teach the caller WorkerUnavailable, deploy that, then merge this.

For Supabase's own ingress that is supabase/edge-functions-ingress#487, which should be deployed before this lands.