Run the dev base in its CI image and move up past a zone stockout

Four fixes for the dev base and up, one commit each.

Closes #16 (closed)

• The dev image is the cloned ref's own CI image. The bootstrap resolves DEFAULT_CI_IMAGE from the clone's .gitlab-ci.yml and the files it includes by path, pulls it, and records it in ~/work/dev-image. When the ref gives no image or the image does not pull, it says FALLBACK and takes the default branch's. When that fails too, it stops and names DEV_IMG. just drift-check asserts the definition still resolves.
• DEV_IMG reaches the VM. install_dev passes it into the bootstrap, up refuses a value that is not an image reference before it creates anything, and state records dev_image.
• A swap rebuilds native gems. The bundle cache records the image that built it, and run.sh runs bundle pristine over every gem with an extension when the image differs. just dev-image [IMAGE] is the swap path.
• up moves to another zone. When a zone has no capacity for the machine type, or does not offer it, up tries the rest of its region, then SIM_FALLBACK_ZONES (default: one zone per other region of the same geography), at most six more creates. A pinned zone never moves: a GCP_ZONE that differs from the secrets file's, or SIM_PIN_ZONE=true. Geo pins both sites, and two-plane's enclave follows the forge.

Which zone up tries

flowchart TD
    A[create in the zone] -->|created| L[landed: state records the zone]
    A -->|no capacity, or the type is not offered| P{zone pinned?}
    A -->|any other error| E[fail as before]
    P -->|yes| F1[fail, naming the knobs]
    P -->|no| N[next zone: rest of the region, then SIM_FALLBACK_ZONES or one per other region]
    N -->|one left, at most six| A
    N -->|none left| F2[fail, naming each zone tried]

What the simulations showed

Two dev bases built from this branch on the default branch of the day, both torn down afterwards.

The checks, each with its control

check	result	control
plain up --base dev	pulled debian-trixie-slim-ruby-3.3.12-golang-1.26-node-22.23-...-chrome-151-... as DEFAULT_CI_IMAGE at master: the string dev-ci-image.sh --ref master prints on the laptop, and the values in master's .gitlab/ci/version.yml	the old pin: bookworm, Ruby 3.3.11, Go 1.25, node 22.12, Chrome 138
encoding_helper_spec.rb in that image (full stack, loads charlock_holmes)	63 examples, 0 failures	none needed
DEV_IMG=<the old bookworm image> up --base dev	the VM's log reads image: <bookworm> (DEV_IMG) and master's own CI runs <trixie>, and run.sh reports Debian 12 and Ruby 3.3.11	before the fix, install_dev started the bootstrap with the branch alone
the trixie image over that bookworm-built bundle, outside run.sh	libicudata.so.72: cannot open shared object file loading charlock_holmes	this is the control for the next row
just dev-image on that base	took the clone's CI image and ran bundle pristine over 62 gems, then reported ruby 3.3.12 with the bundle loading, in 99 s. charlock_holmes loads, the clone stays clean, and the same spec gives 63 examples, 0 failures	the load failure in the row above
up when us-central1-a had no capacity: a real ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS	us-central1-a has no capacity for c2d-standard-8 right now; trying us-central1-b, then landed in us-central1-b. State and down used that zone	none: an unstaged stockout
a default zone that does not offer the type: us-west2-b for c2d-standard-8, set by sourcing the engine, since an exported one pins	us-west2-b does not offer c2d-standard-8; trying us-west2-a, then landed in us-west2-a	the next row
GCP_ZONE=us-west2-b just up, a pinned zone	The zone is pinned ... so up tried no other, and no VM exists	the row above

The offline self-test covers the rest: the fallback's order and bound, the named list, the pin rules, a plain error that never moves the zone, the resolver on a fixture tree and through the files API, DEV_IMG on the SSH command line, and the run.sh rebuild. Removing the fallback, the DEV_IMG pass-through or the rebuild each turns its section red.