docs(website): the three defects the walk found, and the mount that answered one

EVENTS.md §I records that participation history is mounted twice and why --
the third screen to need the notificationPaths.js mapping, for the reason
the first two did -- and the three defects the live walk found with both
suites green on either side of it. EVENTS_PLAN.md says the same in one
paragraph under Phase 14a's verify line.

Two of the three were one mistake in two files: a split reading a STATUS
where it should read a clock.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4

website/EVENTS.md

@@ -1433,6 +1433,25 @@ entirely, which is a distinction probing `/public/events` cannot make, where "no
 definitions and nothing else, so a page for an empty one would publish the single fact that an
 operator has named something they have not announced.
 
+**Participation history is mounted twice, and it is the third screen to need that.**
+`GET /player/events/history` is behind `requireAuth` alone and self-scoped on `req.user.id` — staff
+are a superset of players, so a staff member has an attendance record like anyone else. The WEB is
+what disagrees: `RequirePlayer` sends anyone who is not a `player` out of `/account`, so a single
+mount there is a screen the reviewing admin can never open. The notifications pair hit this exact
+wall in engagement Phase 7 and answered it with two routes, one pair of components and one mapping
+in `lib/notificationPaths.js`; `eventHistoryPath` joins `inboxPath` and `notificationSettingsPath`
+there rather than starting a second file with the same comment at the top of it. The staff path is
+`/admin/events/mine`, in the Events section of the sidebar, and it is the one row in that group
+with no `roles` — every account has a participation history and the server scopes it to the caller.
+
+> **Three defects, and the live walk is the only thing that found any of them.** Both suites were
+> green before it and after each fix. Two were the same mistake in different files — a split reading
+> a STATUS where it should read a clock: the calendar told a visitor an event four days away *did not
+> happen* (it had been cancelled, and the tense of that word follows the clock, not the status), and
+> the event page filed that same future occurrence under *previously*. The third was the mount above.
+> A cancelled occurrence still belongs under what is coming, because *"next Friday is off"* is
+> exactly what somebody checking a calendar came to find out.
+
 > **A venue was never a field, and Phase 14a stopped saying it was.** §I's screens table and the API
 > surface table had both described a venue since the first revision — the definition editor's
 > sections, and what an event page shows. There has never been one: not a column, not a key in

website/EVENTS_PLAN.md

@@ -1730,6 +1730,12 @@ at `seedVersion` 2.
 history.
 **Verify:** both suites; a browser walk of the calendar, an event page, an arc and the history.
 
+**The walk found three defects and the suites found none of them**, which is the argument for the
+walk in one line. Two were one mistake in two files — a split reading a status where it should read
+a clock — and the third was a screen the reviewing admin could not open at all, because
+`RequirePlayer` guards `/account` and the route behind it is role-agnostic. Engagement Phase 7 had
+already solved that one; the fix is its `notificationPaths.js` mapping gaining a third entry.
+
 #### Phase 14b — the app (`android-app` + `docs`)
 
 The app's events screens, and **one prerequisite fix that is in this phase and not after it.** The