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/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`