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 <[email protected]>

src/Auth/RegistrationPage.php

@@ -29,8 +29,9 @@ class RegistrationPage {
 		}
 
 		// phpcs:ignore WordPress.Security.NonceVerification.Recommended -- token identifies the invite; the form submit is nonce-checked below.
-		$token  = sanitize_text_field( wp_unslash( $_REQUEST['us_invite'] ?? '' ) );
-		$invite = '' !== $token ? $this->invites->findByToken( $token ) : null;
+		$token = sanitize_text_field( wp_unslash( $_REQUEST['us_invite'] ?? '' ) );
+		// Only the token's hash is stored, so hash the submitted token for lookup.
+		$invite = '' !== $token ? $this->invites->findByToken( Invite::hashToken( $token ) ) : null;
 
 		$error   = '';
 		$success = false;