Init mutates runner state without runnerMu, racing Stop/Destroy #23

Split out of #20 / #22 rather than folded into that PR: closing it means giving Init a locking discipline, which is a change of its own.

Problem

Runtime.Init reads and writes s.runnerEnvironment and s.cacheLocation with no lock, while Stop and Destroy touch both under runnerMu:

• Init checks if s.runnerEnvironment == nil and calls CreateRunnerEnvironment, which assigns s.runnerEnvironment and s.cacheLocation — all unlocked.
• Init then uses s.runnerEnvironment.Init(ctx), .NewProcess("uv", "sync"), and GenerateOpenAPI.
• Since fix: supervise the uvicorn process and make repeated Start safe (#19) #21, Stop reads s.runnerEnvironment under runnerMu. Since fix: make Destroy self-contained for execution cleanup (#20) #22 both Stop and Destroy write it (s.runnerEnvironment = nil on a successful shutdown).

These are concurrent gRPC handlers — the same reasoning that put runnerMu around Start/Stop in #21 applies here.

Concrete failure

1. Init evaluates s.runnerEnvironment == nil as false (an environment from an earlier Init).
2. Destroy runs, shuts the environment down and sets the field to nil.
3. Init reaches s.runnerEnvironment.Init(ctx) and dereferences a nil interface — a panic, caught by the deferred s.Wool.Catch() but a crash path all the same.

A narrower version wipes cacheLocation while Init is populating it, or has Init complete against an environment that was just shut down.

Why it was not fixed in #22

The fix is not local to the lines #22 touched. Doing it properly means either holding runnerMu across Init's runner-environment section — which serialises Stop/Destroy behind a potentially long docker pull — or capturing the environment in a local under the lock and threading it through Init and GenerateOpenAPI. Both are design decisions about Init, not fallout from the Destroy fix.

Suggested direction

Capture the environment once under runnerMu and use the local for the rest of Init, so a concurrent teardown cannot nil the value mid-flight, and publish cacheLocation/runnerEnvironment under the same lock. Worth checking against core#415's lifecycle contract first — a terminal state there may make part of this moot.

Verification should include a -race test running Init concurrently with Destroy; the current suite never overlaps them, which is why go test -race is green today.