#2619 gatorwalk-factory: test harness on the real swamp engine (GW-7)

Part of the gatorwalk-factory rebuild of @swamp/software-factory (gatorwalk-factory/ in swamp-extensions; GW-1..GW-6 shipped as #2576, #2584, #2588, #2598, #2611, PRs 327-329, 333, 334). Read gatorwalk-factory/README.md and DESIGN.md first.

Today every gatorwalk test runs against hand-written fakes (extensions/models/_lib/fake_swamp.ts and memoryStore). The plan's lesson from software-factory (#1487) is that fakes hide the engine's real behaviour, and GW-6 proved it: a manual smoke run in a real swamp repo found that swamp reads a model's type from the source as a string literal, so a type given as a constant never registered. No unit test could see that.

GW-7 builds an automated harness that drives gatorwalk through the real swamp CLI in a throwaway repo, and a first suite on it.

Harness:

• A temporary swamp repo per test run: swamp init --tool none, then swamp extension source add . No manifest.yaml is needed (swamp loads extensions/models without one). Clean up afterwards.
• Helpers to create a lifecycle holder (write the lifecycle into the definition's globalArguments), run methods by direct type execution with --log, and read results back with swamp data get --json. Method output goes to the log.
• Never depends on live cloud services or the network.

First suite (each of these was done by hand in the GW-6 smoke run, see the conformance review on #2611):

• both model types register (@swamp/gatorwalk-factory/lifecycle and /work-item);
• holder validate on a valid lifecycle and on one with errors (including a platform dollar-brace expression), and new_key;
• start under a generated key; status; a payload that breaks its schema exits non-zero and its errors stay on the run; a stale write is refused and writes nothing; record, advance, approve; reset with repin adopts an edited holder;
• payloads and pinned lifecycles read back from swamp's storage with the digest they were written with (an open GW-4 question: the digest is taken before storage and checked after the round trip);
• build-swamp-extension from start to release through the CLI.

Decide and document: how the suite runs in verification. The gatorwalk-factory target in verification/checks.yaml grants tests only --allow-read; the harness needs to run the swamp binary, write a temp dir and read env. Either widen that target (a trust-root change that the CI integrity review will audit) or give the harness its own target, and say why. Record which swamp version it ran against.

Out of scope: remote workers and serve (the remote-worker definition shape stays unconfirmed; note it), the driving skill (GW-8). Nothing is published: gatorwalk-factory stays manifest-free until go-live.