feat(clubs): pick the club shots are filed under

[btripp]

Why was this required?

Every shot the server records is filed under a club (club on each shot), but the phone had no way to see or change which one. The only way to switch clubs was walking back to the kiosk between shots. On a headless Pi there was no way at all, and every shot was filed under whatever club was last set. That breaks the per-club numbers the kiosk and the phone both show.

The server already owns the whole surface: set_club, a club_changed broadcast to every client, and the current club in session_state. Mobile already had the club list mirrored (#19) and ClubChangedPayload typed. Nothing was wired to them.

What does this PR do?

Adds a Club row to the Live screen. Tapping it opens a sheet listing every club, grouped as Irons / Hybrids / Woods like the kiosk's picker, with the current one highlighted. Picking one sends set_club.

• Shows what the server confirmed, not the last tap. The server ignores an unknown club with no reply, so the store only changes on club_changed (or the club in session_state on connect). There's no optimistic update to roll back.
• Sends only over a live connection. Socket.IO keeps the socket through a transient drop and buffers emits, replaying them on reconnect. A pick made during a Wi-Fi hiccup would otherwise land later and silently re-file the shots that follow. This is the same issue raised on feat(profiles): mirror the server's profile roster #21.
• Disabled unless connected. A tap can't look like it worked when nothing was sent. If the connection drops while the sheet is open, the sheet closes.
• Cleared on a deliberate disconnect or a switch to a different server; kept through a transient drop.
• Follows changes from other clients, such as the kiosk or a connected simulator.

Not included: the roadmap's "prompt for a club on first connect", swing-speed training implements (set_training_implement), and profile selection. The profile picker follows once #21 lands.

Automated tests

• __tests__/socket.test.ts, 11 added: club seeded from session_state; kept when a snapshot has no club (older servers); club_changed applied; malformed club_changed ignored (missing, non-string, null); set_club payload while connected; store unchanged until the server confirms; nothing sent before connecting; nothing sent during a transient drop, even after reconnecting; club kept through a drop; cleared on deliberate disconnect(); cleared when connecting to a different server. The socket fake now tracks connected, the same way feat(profiles): mirror the server's profile roster #21's does.
• __tests__/ClubPicker.test.tsx, 10 added (RNTL interactions): shows the server's club / "not set"; opening lists all three groups with the current club marked selected; picking calls setClub and closes; the row keeps the old club until confirmation; Done closes without sending; disabled while disconnected, connecting and error; the sheet closes if the connection drops while it's open.
• __tests__/LiveScreen.test.tsx: the Live screen renders the picker once connected.

I checked that the component tests catch real breakage: removing the disabled guard and the close-on-drop guard makes 4 tests fail.

All run on the head commit: npm ci, npx expo-doctor (21/21), npx tsc --noEmit, npm test -- --ci --runInBand (14 suites / 171 tests), npm run format:check, npx expo lint, npx expo export --platform all.

Manual (human) testing

Platform: iOS 26.5 simulator, iPhone 17 Pro. Build: Expo Go 57.0.9, not a development or release build. Server: the OpenFlight Python server in --mock mode from open-flight/openflight main.

1. By hand: connected, opened the Club row and picked seven clubs in a row (3-iron, 9-iron, PW, GW, 5-wood, 2-iron, 9-iron) while simulating shots. The row followed each pick, and the server logged a club_changed broadcast for every one, in order.
2. Scripted with XCUITest, driving Expo Go by accessibility label. It typed the server address, tapped Connect, tapped the Club row (the sheet opened with Driver highlighted), tapped Pitching Wedge, and the row updated. The server broadcast club_changed {"club": "pw"}.
3. Reconnect behavior (a temporary in-app probe, not committed):
   • the club was seeded from session_state on connect;
   • a change made by a second Socket.IO client appeared on the phone;
   • the server was stopped mid-session, the row dimmed and kept its club, and a pick made while disconnected was not delivered after the server came back (zero club_changed broadcasts after the restart).
4. Checked dark and light appearance.

Club list	After picking

The blue gear is Expo Go's developer button, not part of the app. In Expo Go it overlaps the sheet's Done button; it isn't there in a real build.

Not tested: Android (no emulator run for this branch), a development or release build, a physical device, and swing-speed mode.

Server/API contract impact

No server change. Consumes the existing contract:

• Emits set_club {club}, where club is one of the ClubType values mirrored in data/clubs.ts.
• Consumes club_changed {club}, and the club field of session_state.

Adds optional club?: string to SessionStatePayload. It's optional because older servers don't send it; when it's absent the current club is kept, not cleared.

Overlap with #21: both PRs add the same "emit only while connected" guard (emitWhileConnected here, emitProfileMutation there). Whichever merges second should switch to the other's helper so there's one copy. I'll do that when rebasing.

AI assistance

AI assistance (Claude Code) wrote the store and socket changes, the picker component and the tests, and ran the checks and simulator verification above. The design choices (confirmed-only display, the connected-only guard, clearing on a server switch) follow the review feedback on #21 and the kiosk's own set_club / club_changed handling. I tested the picker by hand on the simulator.

Checklist

• This PR has one coherent objective and contains no unrelated changes
• New or changed behavior has automated tests, or I explained why none apply
• I documented manual human testing with the actual platform/build used
• I documented any OpenFlight server contract impact
• I disclosed substantive AI assistance and personally reviewed every change
• npm ci succeeds
• npx expo-doctor passes
• npx tsc --noEmit passes
• npm test -- --ci --runInBand passes
• npx expo export --platform all succeeds when application code changed
• Documentation was updated where required
• No policy documents are mixed into a product-feature PR
• No unrelated generated files, formatting, or dependency updates are included

[johnpacino]

Looks good