#2734 gatorwalk-factory: drive a swamp-extensions Lab issue end to end through the swamp-club adapter (gap 1)

Part of the gatorwalk-factory rebuild (gatorwalk-factory/ in swamp-extensions). Read gatorwalk-factory/README.md and DESIGN.md ("Trackers", "The swamp-club Lab adapter", "The projection publisher") first. This closes gap 1 in lifecycles/swamp-extensions.md: the lifecycle cannot act on swamp-club.

Goal

A gatorwalk work item can drive a swamp-extensions Lab issue end to end, doing what issue-lifecycle does to the Lab, so the issue looks the same to anyone reading it there. issue-lifecycle stays as it is and keeps driving every other issue. Do not change issue-lifecycle.

What issue-lifecycle does, and what gatorwalk lacks

The reference is the root copy extensions/models/issue_lifecycle.ts with _lib/swamp_club.ts and _lib/lifecycle_recorder.ts, which is the one this repo runs (not issue-lifecycle/extensions/...).

Scope

1. Adapter (@swamp/gatorwalk-factory/swamp-club):
   • a set_type method;
   • a full fetch_issue (body, comments, type, author, authorId);
   • a team-membership check for an issue's author, fail-closed like issue-lifecycle's;
   • a lifecycle-entry writer. Keep the tracker contract and the conformance suite honest. If a method is Lab-only, say how it sits beside the shared contract.
2. Lifecycle entries through publish. Journal events project to structured lifecycle entries, idempotent through the delivery ledger like the existing comments. The one-writer rule holds: publish stays the only writer of status, and a stage requests transitions rather than moving the ticket.
3. Wiring swamp-extensions.yaml:
   • triage sets the type;
   • attest posts through the adapter and records the id it returns;
   • notify checks the roster and posts the ripple through the adapter. A stage has one work block. Choose, and justify, whether these stay interactive stages where the agent calls the adapter, or become mode: method stages (none exist yet in a bundled lifecycle). Update the file header, the mapping, and the skill's driving reference.
4. Guard against two drivers. claim refuses an issue that already has an issue-lifecycle instance (@swamp/issue-lifecycle, named issue-<N>) in the repo, with a clear message. This is a read-only check from gatorwalk's side.

Questions to bring back before building

• Lifecycle entry step names: reuse issue-lifecycle's names (triage_started, classified, plan_generated, verification_passed, attestation_posted, pr_linked, shipped, ...) so the Lab history reads the same, or project gatorwalk's own events under its own names. Coordinator lean: reuse issue-lifecycle's where an event matches.
• Whether the attestation check stays in CI only. validate-attestation already reads the attestation from the Lab by commit. The lean is yes, with no read-back in the lifecycle.

Sequencing

#2730 is editing swamp-extensions.yaml now, and #2732 (per-stage complete exits) follows it. Do scope items 1, 2 and 4 first. Rebase onto #2730 before the wiring in item 3.

Done when

• The adapter methods exist, with unit tests against the Lab fake and conformance coverage.
• publish writes lifecycle entries idempotently. A re-run posts nothing new.
• swamp-extensions.yaml drives type, attestation and thank-you through the adapter, and gap 1 is marked resolved in the mapping.
• claim refuses an issue that issue-lifecycle has an instance for.
• A real-engine integration test drives a work item against the Lab fake from claim to notify and checks the entries, the type, the status sequence and the ripple.

Out of scope

• Any change to issue-lifecycle.
• Migrating in-flight issues between drivers.
• Gap 7 (restart semantics) and gap 3 (where a workflow lives).