First-class managed_club marker (server-scoped, forward-compatible to per-user)

[Sootopolis]

Problem

CCAS has no first-class representation of "a club the user manages". The club table holds many clubs — most are scouted/opponent/recruited-from clubs ingested incidentally, not clubs the user runs CCAS for. Today the only way to tell them apart is leaky side-effect signals (e.g. "has a recruitment_alias" or "has a membership_run"), which conflate management with having run a job once — reconciling an opponent club's roster to scout it would falsely mark it managed.

This bites any feature that must act on "my clubs" rather than "all known clubs" — directly surfaced while rescoping #45 (default scheduled jobs), where seeding History/Membership for all clubs would blow up the DB.

Proposal

Introduce a minimal, first-class managed-club marker:

• New table managed_club (club_id BIGINT PRIMARY KEY REFERENCES club(club_id) ON DELETE RESTRICT) (preferred over a club.managed boolean — keeps lifecycle concerns out of the club row and extends cleanly).
• Server-scoped for now (single-user v0, Epic: CLI v0 (Phase 1) #40). Forward-compatible to per-user: when auth lands (Backend auth, authz & abuse defenses (Phase 2 server hardening) #66) the PK becomes (user_id, club_id) and the existing rows migrate to the bootstrap user.
• A club becomes managed by an explicit act, never derived — candidates: a new ccas manage <slug> command, on first recruitment-criteria set, and/or via CLI club-context: current_club + ccas use <slug> #86's ccas use <slug>. (Pick the trigger(s) as part of this issue.)
• Club/new ManagedClub companion: createTable, selectAll/selectIds, markManaged(clubId), unmanage(clubId), isManaged(clubId).

Uses

• A non-leaky source for per-managed-club scheduling (blocks #B / per-managed-club History+Membership seeding).
• A validation hook for ScheduleRoutes ("only schedule per-club jobs for managed clubs").

Out of scope

• Users / auth / authz — that's Backend auth, authz & abuse defenses (Phase 2 server hardening) #66. This issue deliberately does not model users, so it does not gate on Backend auth, authz & abuse defenses (Phase 2 server hardening) #66 or CLI club-context: current_club + ccas use <slug> #86.
• The per-managed-club seeding itself — separate follow-up.

Relationship

• Split out of Bootstrap default JobSchedule rows for server-internal kinds at first boot #45 (which now seeds only the global MatchRef/ClubData maintenance jobs).
• Under epic Epic: CLI v0 (Phase 1) #40 (CLI v0).

[Sootopolis]

Context: #45 shipped (globals-only) in #103 / 31d8874. This issue (first-class managed_club marker) is the prerequisite for #102.

[Sootopolis]

Future: multi-user + multi-device (deferred)

The initial managed_club marker is server-scoped (PK club_id alone), so on a shared DB (Neon) one user's ccas clubs remove un-manages the club for everyone. Intended for v0 (single-user, loopback — #40). Two distinct axes to handle later:

1. Ownership — per user → Backend auth, authz & abuse defenses (Phase 2 server hardening) #66 (auth). PK becomes (user_id, club_id); existing rows migrate to the bootstrap user. The shared DB then holds each user's full managed set independently.

2. Active subset — per device → CLI club-context: current_club + ccas use <slug> #86 (CLI club-context). A user who is admin of several Chess.com clubs may want to manage different subsets on different devices. That is a device-local working set, not ownership — it belongs in client config (current_club / default_clubs), not the shared DB row. The DB says what you can manage; the device picks what you're currently managing.

So: ownership in the DB (#66), device working-set in client config (#86). Keep the two separate — don't push device preference onto the shared managed_club row.

[Sootopolis]

Shipped in #104 — squash-merged to main as 9f79396. Server-scoped marker + ccas clubs add/remove/list; multi-user (#66) / multi-device (#86) refinements remain noted above for later.