As an instruktør I want to see joint session history for a class slot so I can avoid repeating what a colleague already trained

[ChristopherRotnes]

Summary

With `user_gyms` in place (#136), instruktører at the same gym can now be scoped together. This issue builds the read side: when viewing history for a recurring class (e.g. "Styrke Mandag 18:00"), an instruktør should see all sessions linked to that `gym_calendar_id` — including sessions logged by co-instruktører — so the group avoids repetition across weeks.

Priority

High

Data model

No schema change needed. `sessions` already has `gym_calendar_id`. A query joining `sessions → gym_calendar` filtered by class name/time and scoped to the same `sporty_business_unit_id` (via `user_gyms`) is sufficient.

RLS will need a new SELECT policy on `sessions` that allows users to read rows where the session owner belongs to the same gym (same `sporty_business_unit_id` in `user_gyms`).

Acceptance criteria

• New RLS policy on `sessions`: users at the same gym (matched via `user_gyms.sporty_business_unit_id`) can read each other's sessions
• `fetchClassHistory(gymCalendarId)` in `db.js` returns all sessions for a given class slot across instruktører
• UI entry point (location TBD — likely History or a dedicated class view) shows the joint session list for a class
• Opt-out sessions (issue #TBD visibility flag) are excluded from the joint view
• Verified by developer on dev/qa/prod before closing

Out of scope

• Writing or editing another instruktør's session
• Participant-side users
• Cross-gym visibility

[ChristopherRotnes]

Delivered in PR #146 — joint class history panel in History expanded view, lazy-fetched per gym_calendar_id with display name + exercise list per colleague.

[ChristopherRotnes]

We reverted this because the feature didnt work well.