Gigs page: list upcoming gigs from web-jam-back

[JoshuaVSherman]

Gigs page: list upcoming gigs for Tim, read over the WebJamSocketCluster socket — NOT REST (Josh's Path-B decision 2026-07-03: gig reads on BOTH sites ride the socket; the server path for Tim shipped in WebJamSocketCluster#238).

Transport (hard requirement)

• Port JaMmusic's socket plumbing: src/providers/socketClusterMessages.ts + src/providers/fetchGigs.tsx in the JaMmusic repo are the reference (connection options/host included — copy that pattern).
• Flow for Tim: connect, transmit gigsForArtist with artist tim (see WebJamSocketCluster src/AgController/index.ts ~lines 95–105 for the exact expected payload), and listen on receiver allGigs:tim for the gig array.
• Do NOT call web-jam-back's REST /gig route from this page. PR Gigs page: list upcoming gigs from web-jam-back #19 was rejected for exactly that (2026-07-08).

UI (reuse what's already built)

PR #19's UI layer was good — reuse its GigList component, CSS, sorting/filtering (upcoming-only, ascending), ticket-link rendering, and tests; only the data transport changes (fetch → socket). Cherry-pick or re-create from the closed PR's branch agy/3-gigs-page-list-upcoming-gigs-from-web-ja.

Acceptance

• Gigs render from the socket message allGigs:tim (verify with the browser devtools WS frames, not just tests)
• Upcoming-only, ascending by date; graceful empty state (Tim has no gigs yet — empty is the normal case today)
• Unit tests mock the socket layer (as JaMmusic's tests do), coverage gate stays green

[JoshuaVSherman]

Design change (Josh, 2026-07-03): gigs are read via WebJamSocketCluster (artist-scoped socket messages, port JaMmusic's socket plumbing), NOT web-jam-back REST as this issue's body says — Path B of the Atlas consolidation (web-jam-back#897, WebJamSocketCluster#237). Blocked until #237 ships. Open design question before building: whether gig admin WRITES (issue #5) go via socket or web-jam-back#887's REST CRUD.