Security fixes: CSV injection, policy body output, invite hashing, slot datetimes

Four fixes from a security review pass:

- Neutralise CSV formula injection in the payments export: fields with a
  leading =, +, -, @, tab, or CR (e.g. a hostile student display name) are
  apostrophe-prefixed in PaymentReport::csvLine() so they open as text in
  Excel/Google Sheets. Fixes #39.
- Sanitise policy bodies with wp_kses_post at output in
  PolicyEndpoint::index() (the booking JS renders that HTML raw), so a
  future write path that forgets kses can never become stored XSS.
  Fixes #40.
- Store invite tokens hashed (SHA-256) at rest: a database leak can no
  longer redeem pending invites. The registration link is shown once, at
  creation; the pending list shows email/invited date; lookups hash the
  submitted token. Existing plaintext pending invites must be re-issued.
  Fixes #41.
- Validate availability slot datetimes on both creation paths (REST and
  admin form) via AvailabilitySlot::normalizeDateTime(): canonical and
  datetime-local forms normalise to Y-m-d H:i:s, garbage and end <= start
  are rejected (REST 400) instead of reaching the DATETIME column or
  throwing inside the weekly-series date arithmetic. Fixes #42.

composer test (204 tests, 594 assertions), PHPStan L6, and PHPCS all green.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/features/account-registration.md

@@ -18,7 +18,7 @@ Stored in the `us_registration_mode` option (default `invite`):
 |--------------------|------------------|--------------------------------------------------------|
 | `id`               | BIGINT UNSIGNED  | Primary key                                            |
 | `email`            | VARCHAR(191)     | Invited email address                                  |
-| `token`            | VARCHAR(64)      | Opaque token embedded in the registration link         |
+| `token`            | VARCHAR(64)      | SHA-256 hash of the token embedded in the registration link (raw token is never stored) |
 | `role`             | VARCHAR(32)      | Role granted on acceptance (default `us_student`)       |
 | `status`           | VARCHAR(20)      | `pending` / `accepted` / `revoked`                     |
 | `invited_by`       | BIGINT UNSIGNED  | WordPress user ID of the studio admin who invited       |
@@ -34,16 +34,16 @@ recorded in `us_policy_acceptances` with `registration_type = account` and
 `registration_id = <new user ID>`.
 
 ## Flow (invite mode)
-1. Studio admin opens **Invites** (`manage_students`) and invites an email; an invite row is created with a token and a registration link.
-2. The invitee opens `[us_student_register]` with the token (`?us_invite=<token>`).
+1. Studio admin opens **Invites** (`manage_students`) and invites an email; an invite row is created storing the token's SHA-256 hash, and the registration link (with the raw token) is shown **once** in a notice. To re-send a lost link, revoke and re-invite.
+2. The invitee opens `[us_student_register]` with the token (`?us_invite=<token>`); the lookup hashes the submitted token and matches it against the stored hash.
 3. The form pre-fills the email and collects a display name and password, and renders the signup-scoped published policies, each with a required acceptance checkbox.
-4. On submit, the token is re-validated; a `us_student` user is created, the policy acceptances are recorded (`account` type), the invite is marked `accepted`, and the user is logged in.
+4. On submit, the token is re-validated (hashed lookup); a `us_student` user is created, the policy acceptances are recorded (`account` type), the invite is marked `accepted`, and the user is logged in.
 
 ## Admin Interface
 **Invites** in wp-admin (`manage_students`, studio admin only):
 - Select the **registration page** (the page hosting `[us_student_register]`), stored in the `us_registration_page_id` option; invitation links point there (falling back to the home page if unset)
-- Invite an email (creates a pending invite + link)
-- List pending invites; revoke an invite
+- Invite an email (creates a pending invite; the link is displayed once, at creation only)
+- List pending invites (email + invited date); revoke an invite
 
 ## Frontend Shortcode
 - `[us_student_register]` — the registration page. Shows the form for a valid pending invite; otherwise shows an "by invitation only" message (in `invite` mode).

docs/features/availability-management.md

@@ -46,6 +46,12 @@ offering/duration before selecting a slot to register for.
 
 `GET` supports query params: `instructor_id`, `offering_id`, `duration_minutes`, `from` (datetime), `to` (datetime).
 
+`POST` validates `start_dt`/`end_dt` (admin form and REST alike) via
+`AvailabilitySlot::normalizeDateTime()`: the canonical `Y-m-d H:i[:s]` and HTML
+`datetime-local` (`Y-m-d\TH:i[:s]`) forms are normalised to `Y-m-d H:i:s`;
+anything else — or an end not after the start — is rejected (REST responds
+`400 invalid_datetime`; the admin form is a no-op).
+
 ## Implementation
 - Repository: `Unsupervised\Schedular\Availability\AvailabilityRepository`
 - Model: `Unsupervised\Schedular\Availability\AvailabilitySlot`

docs/features/payment-reporting.md

@@ -54,6 +54,11 @@ and `instructor_id` query params as the page and returns `text/csv` with a
 `Content-Disposition: attachment` header. Instructor requests are scoped to
 their own rows regardless of `instructor_id`.
 
+Fields that a spreadsheet would interpret as a formula (leading `=`, `+`, `-`,
+`@`, tab, or CR — e.g. a hostile student display name) are prefixed with an
+apostrophe so the export can never carry CSV formula injection into Excel or
+Google Sheets.
+
 ## Implementation
 
 - Report aggregator (pure totals + CSV): `Unsupervised\Schedular\Payment\PaymentReport`