Human-friendly UI on top of the JSON DELETE /idp/account endpoint
(#391). Public unauthenticated page at /idp/account/delete; auth
happens at submission time via username + password. Matches the
existing /idp landing and /idp/register pattern — no JavaScript
required, accessibility-first form-encoded POST.

## Form fields
- Username or email
- Current password (re-entry as proof of possession)
- Type your username again to confirm (destructive-action UX guard)
- Optional checkbox: also delete pod data

## Routes added
- GET  /idp/account/delete  → render the form (or single-user disabled message)
- POST /idp/account/delete  → process submission

Same 5/min/IP rate-limit as the JSON endpoint. Single-user mode shows
the disabled-message page instead of the form on both GET and POST,
matching the JSON endpoint's 403 policy. Operator path remains the
CLI (`jss account delete`).

## Internal refactor
Factored the shared "delete + optional purge" logic into
`deleteAccountAndOptionallyPurge(request, account, purgeData)` so the
JSON endpoint and form endpoint share the same path. Pod-data purge
uses `account.podName` (per #391 pass 2) and path.relative (per #391
pass 3) so the case-sensitivity fix and FS-root edge case carry over.

## Tests added (8)
- GET renders form HTML with all required fields
- POST happy path → success page + login fails after
- POST with purgeData=on wipes pod tree
- POST with mismatched confirmUsername → form re-rendered with error
  + username pre-filled for retry, account untouched
- POST with wrong password → form re-rendered with error, account
  untouched
- POST with missing fields → form re-rendered with error
- Single-user mode: GET renders disabled message (no form)
- Single-user mode: POST also renders disabled message — does NOT
  delete (verified: account still functional after the POST)

636/636 full suite passes.

Six fixes per the review:

1. handleDeleteAccount now actually uses the new
   deleteAccountAndOptionallyPurge helper. The helper was added in the
   prior commit but the original function still had its own inline
   purge block — divergence risk. Now both endpoints share the same
   path verbatim.

2. JSDoc reference \`handleAccountDeletePost\` → \`handleAccountDeleteForm\`
   (the actual exported name). Two route methods (GET + POST) live in
   the same handler; doc updated to reflect that.

3. JSDoc claimed failures "redirect back to the GET form with an
   error message" — the implementation actually re-renders the form
   in-place with status 200. Doc corrected to match (single response,
   no redirect).

4. Form handler now respects the \`purged\` return from the helper.
   When the user requested purgeData but the purge didn't run (fs
   threw, path-relative check rejected), the success page surfaces a
   "your account was deleted but the pod-data purge did not complete"
   notice. Account deletion succeeded — that part can't be undone —
   but the operator may need to finish cleanup.

5. Warning copy on the form softened: was "any active sessions will
   be removed", which the server doesn't actually implement.
   Now: "future sign-ins with this username will fail" + an italic
   note that already-issued access tokens may remain usable until
   their expiry.

6. Same correction on the success-page copy.

17/17 delete-account tests still pass.

…ername UX confusion

Four polish fixes:

1. handleAccountDeleteForm reference in deleteAccountAndOptionallyPurge's
   JSDoc was still mis-named handleAccountDeletePost (one stray spot the
   pass-1 fix missed).

2. accountDeletePage's JSDoc updated: "redirect-back-with-error" was
   wrong (we re-render in place); also documented the new purgeFailed
   param added in pass 1.

3. + 4. Form label simplified from "Username or email" → "Username".
   Confirms a user point: JSS doesn't really do email — no SMTP, no
   verification flow, no recovery flow, the HTML register form doesn't
   ask for email at all. The "email" field in accounts.js is a
   data-layer artifact (auto-generates <username>@jss if absent) and
   isn't surfaced anywhere user-facing. Saying "username or email" on
   this form mismatched reality and confused the destructive-action
   confirm field ("Type your username again to confirm"). Now both
   fields consistently say username, matching what users will actually
   enter.

Server-side authenticate() still tries findByUsername then
findByEmail for back-compat with anyone who registered programmatically
with a real email; that fallback is just unreachable from this form
since the field never accepts email anymore. Cleaning that up across
the wider auth surface is a separate PR.

17/17 delete-account tests still pass.

Three small fixes:

1. handleAccountDeleteForm JSDoc clarifies it's POST-only; GET is a
   separate route in index.js that just renders the form via
   accountDeletePage. Pass-1 wording was 'GET / POST' which implied
   both routes flow through this handler.

2. accountDeletePage's JSDoc still mentioned 'identifier (username or
   email)' from before the email simplification in pass 2. Now says
   'username + password' to match the actual UI.

3. The checkbox copy promised 'Removes <dataRoot>/<username>/' but
   the purge path is derived from account.podName (which can differ
   from the lowercased username on case-sensitive FS, per #391
   pass 2). Softened to 'Removes the pod folder on disk' — accurate
   without leaking the path shape.

17/17 tests pass.

The comment claimed @fastify/formbody puts fields directly on
request.body, but no such plugin is installed. JSS's wildcard
parseAs:'buffer' content parser at server.js:190 means request.body
arrives as a Buffer; the URLSearchParams parse below is what's
actually load-bearing. Comment updated to describe what the code
genuinely does.

…e-user, flip purge default to ON

Five fixes (4 from Copilot, 1 from maintainer call to flip the default):

1. handleAccountDeleteForm now uses findByUsername + verifyPassword
   instead of authenticate(). authenticate() writes lastLogin as a
   side effect, which is wrong shape for a destructive proof-of-
   possession check (and would fail the deletion if the account file
   weren't writable). Mirrors handleChangePassword and the JSON
   handleDeleteAccount.

2. Warning copy corrected. Previous text said "any active sessions
   will be removed" + "WebID URI will become a tombstone" — the
   server does neither. Now: "Future sign-ins with this username will
   fail" + "external links to your WebID URI will become dangling"
   (since pod data is being wiped, the URI no longer resolves).

3. Single-user mode now returns 403 from both GET and POST routes
   (matched HTML body kept). Consistency: /idp/register's
   disabled-route policy is 403, the JSON DELETE endpoint is 403,
   and now the form path is too.

4. Body-parsing comment corrected: was claiming @fastify/formbody is
   registered (it isn't); JSS uses parseAs:'buffer' for `*` so body
   arrives as a Buffer and the URLSearchParams parse is the
   load-bearing logic.

5. Form's purge default flipped from off → ON. The checkbox is now
   `keepData` (inverse of the JSON endpoint's `purgeData`), default
   unchecked = purge-on. A user filling out the form is leaving the
   server; wiping their pod data with the account is the expected
   shape, and "Keep my pod data on this server" is the explicit
   opt-out. The JSON DELETE endpoint keeps `purgeData: false` as the
   default (matches the CLI's --purge being opt-in for operator
   scripts; programmatic callers shouldn't accidentally wipe data).
   Form and JSON endpoint diverge deliberately because the use cases
   differ.

Tests:
  - happy path now expects pod data wiped by default + login fails
  - new test for keepData=on (opts out of purge; account still
    deleted, pod data preserved)
  - single-user GET / POST now expect 403
  - form-renders test now checks for name="keepData"

17/17 delete-account tests pass.

…tion, fix confirm comment

Three fixes:

1. Warning copy now describes the conditional behavior accurately:
   'By default your pod data is also wiped — check the box below if
   you want to keep it.' Previous wording said pod data 'will be
   removed' unconditionally, which becomes wrong if the user checks
   the keep-data opt-out.

2. Path-safety rejection (when isProperChild is false) now logs a
   warn with path/dataRoot/podName context so operators can diagnose
   any 'purge did not complete' message that wasn't a fs.remove
   throw. No path leaks to the client; signal stays in server logs.

3. Comment on the destructive-action UX guard was misleading. It
   claimed the case-sensitive compare prevents typos hitting a
   different (lowercased) record — but findByUsername lowercases
   internally, so 'Alice' + 'Alice' both resolve to the 'alice'
   record. The compare is purely the typing-it-twice confirmation
   pattern (typo catch / accidental-submit guard); doesn't gate which
   record gets deleted. Comment now reflects what the code actually
   does.

17/17 tests pass.

…elete-form response

Real security findings. The delete-account form takes a current-password
re-entry and the success/error pages echo state — neither should be
cacheable or embeddable in an iframe. Both threats (cache replay,
clickjacking) are real on a destructive endpoint.

Added a small exported helper:

  setNoCacheClickjackHeaders(reply):
    Cache-Control: no-store
    Pragma: no-cache
    X-Frame-Options: DENY
    Content-Security-Policy: frame-ancestors 'none'

Wired into:
  - GET /idp/account/delete (form + 403 disabled-message variant)
  - POST handler entry point — covers every return path (success,
    error re-render, single-user 403, missing-field, mismatched
    confirm, wrong password)

Tests added (2):
  - GET response carries all four headers
  - POST response carries them on both error (missing fields) and
    success (full delete) paths

19/19 delete-account tests pass.