Next healthcheck due date, plus a test suite (hc-nkq)

Lets a technician record when a site should next be looked at, and surfaces
that in the dashboard so it can be used for planning.

Server:
- migration 0002 adds healthchecks.next_due, a VARCHAR(10) 'YYYY-MM-DD'
  calendar date rather than a timestamp — it's a diary date with no
  time-of-day, and a timestamp would render as the wrong day off-server.
- Kept per-session rather than on a sites table, so the history of what was
  scheduled when is preserved. A site's current next-due is the value on its
  most recent session: if the latest visit scheduled nothing, the site reads
  as unscheduled rather than showing the just-completed visit as overdue.
- Validate::optionalDate() round-trips through createFromFormat, which
  rejects both '2026-2-3' and '2026-02-30' (silently rolled to March 2nd).
- next_due follows the same missing-vs-null PUT contract as finished_at, and
  lives in its own Store::setNextDue() so finishing or reopening a session
  never disturbs the date and vice versa.
- Dashboard shows it on the site list, the per-site session table and the
  session detail, flagged overdue / today / soon (within a fortnight).

Plugin:
- Date control on both the active and finished panels — the moment you know
  when to return is often wrap-up, after the report is generated.
- Write-through like every other mutation. Bad input is rejected with a
  notice rather than silently clearing an existing date.
- Included in both the Markdown and HTML reports.

Tests (new — tests/, export-ignored from the plugin zip):
- Hand-rolled harness, no composer/PHPUnit, in keeping with the repo.
- 42 tests: plugin-side date parsing units, plus server integration tests
  driven over real HTTP against a temp `php -S` instance with a throwaway
  SQLite DB, so a real server/config.php is never touched.
- Mutation-checked: dropping the array_key_exists guard on PUT fails three
  tests, as intended.

CLAUDE.md

@@ -52,13 +52,36 @@ bd close <id>         # Complete work
 
 ## Build & Test
 
-There is **no build step, no package manager, and no test suite**. Plain PHP on both
-sides; the only third-party code is a vendored copy of Plugin Update Checker under
+There is **no build step and no package manager**. Plain PHP on both sides; the only
+third-party code is a vendored copy of Plugin Update Checker under
 `vendor/plugin-update-checker/` (do not hand-edit it — see README for the refresh
 procedure).
 
-Quality gate for a change is a syntax lint of the files you touched, **against the
-right PHP version for that half of the repo** (see Conventions):
+```bash
+php tests/run.php            # everything
+php tests/run.php plugin     # plugin unit tests only (runs on PHP 7.4+)
+php tests/run.php server     # server integration tests only (needs PHP 8.1+)
+```
+
+The suite is a hand-rolled harness in `tests/lib/` — no PHPUnit, no composer,
+matching the rest of the repo. Two kinds of test:
+
+- `tests/plugin_test.php` — unit tests for the pure static helpers on
+  `ATT_HC_Session`. That class calls no WP functions at load time, so defining
+  `ABSPATH` is enough to require it; anything needing a real WordPress runtime is
+  out of scope here.
+- `tests/server_test.php` — **end-to-end over real HTTP.** The runner copies
+  `server/` to a temp dir, gives it a throwaway SQLite DB and config, and starts
+  `php -S` against it. A developer's real `server/config.php` (gitignored, may
+  point at live MySQL) is never read or touched. Skips itself with a clear message
+  if `pdo_sqlite` is missing.
+
+Exit code is non-zero on failure, so it works as a pre-push gate. Add a test with
+`test('name', function () { ... })` and the `assert_*` helpers in
+`tests/lib/harness.php`.
+
+Also lint the files you touched, **against the right PHP version for that half of
+the repo** (see Conventions):
 
 ```bash
 # Plugin — must parse on PHP 7.4