#2796 gatorwalk-factory: parent, blocked-by, related and duplicate relations in every tracker

Part of the tracker-seam decision (https://claude.ai/artifact/TDidgyVjxKXU7JsNH1baNy). Needs #2794.

gatorwalk has no issue relations at all. The Lab already stores four: swamp-club/lib/domain/lab/relationship.ts:3-21, with routes GET|POST|DELETE /api/v1/lab/issues/{n}/relationships. issue-lifecycle's root client writes them (extensions/models/_lib/swamp_club.ts:525-537). gatorwalk's Lab fork and its Linear adapter touch none.

Change

• The contract gets relate(from, type, to) and unrelate(...) for parent_of | blocked_by | related_to | duplicate_of. fetch returns the issue's relations with a direction. Every write is idempotent; a write through publish or breakdown is also ledgered.
• The built-in backend enforces the Lab's invariants, so all three backends mean the same thing by each relation: one parent per child, one canonical per duplicate, no duplicate chains (a canonical may not itself be a duplicate), no parent cycles (depth 10). See relationship.ts:46-116.
• Lab: port the relationship calls from the root client into gatorwalk's fork (_lib/swamp_club.ts), keeping the fork's TrackerError model. blocked_by needs an admin key; without one the error is auth. Note that duplicate_of does not change the Lab status.
• Linear: parent via issueUpdate(parentId), and issueRelationCreate / issueRelationDelete for blocks, duplicate and related. Relations are read through the issue query.
• The fakes and the conformance suite gain the relation checks, including every invariant refusal.

Done when

• Conformance covers relate, unrelate, read-back and the invariants for all three backends against their fakes.
• DESIGN.md "Trackers" records that the tracker owns relations: swamp reads them at decision points, never reconciles them, and a relation changed in the tracker is seen at the next read.