#2631 gatorwalk-factory: swamp-club Lab adapter

Part of the gatorwalk-factory rebuild of @swamp/software-factory (gatorwalk-factory/ in swamp-extensions; GW-1..GW-6 shipped, #2576 through #2611). Read gatorwalk-factory/README.md and DESIGN.md first.

@swamp/issue-lifecycle keeps a swamp-club Lab issue in step with the work: it records a lifecycle entry and moves the issue's status on every transition, assigns the issue, and posts the verification attestation that CI checks before a PR can merge. Gatorwalk has no connection to swamp-club, so it cannot yet run work in this repo end to end, even with the swamp-extensions lifecycle (filed separately). This adapter is the swamp-club counterpart of the Linear adapter in the rebuild plan (GW-16 to GW-18), and should follow the same design.

Scope, from the plan's tracker design:

• Swamp owns the facts; the Lab issue is a view. A projection publisher replays a work item's journal to the Lab issue, idempotent on (work item, journal version), triggered explicitly (and later by a sweep or a driver). One writer per Lab field.
• Start a work item from a Lab issue number, keeping the issue number as an external ref (never the instance name), with a way to find the work item for an issue.
• Post a verification attestation to swamp-club from a stage, so a PR opened by a gatorwalk work item passes CI's attestation check. CI checks attestations by commit, so nothing on the CI side changes.
• Credentials from swamp auth or a vault reference, never from lifecycle data.
• No network calls from the state piece: the adapter runs outside it, as its own model or methods, as the plan requires.

Reuse what issue-lifecycle already has (its swamp-club client, the attestation endpoint, lifecycle-entry payloads, the known swamp-club limits such as #2284) rather than writing a second client, and say what is shared and how.

Tests use a local HTTP server standing in for swamp-club; never the live service. Nothing is published.