fix(identity): stop pointing members and operators at the portal being retired

[PBernaerts]

Rebrand task 6f-pre, the blocker that has to land before 6f deletes Authelia.

Why this exists

Wizarr's wizard steps and invite copy live in its SQLite database, not in this
repo, so CI checks none of it and the 6f sweep would have missed it entirely.
Deleting Authelia with these in place breaks the join path for every new member.

What the sweep found

The database was swept column by column (skipping credential-bearing columns)
and is now clean: zero rows anywhere name the old portal.

Row	Reachable?	Problem
step 41 "Je login"	yes, in the Dutch bundle both open invites serve	button pointed at Authelia's reset form, and the mail subject was wrong
steps 28, 35	no, in no bundle	named the old portal
bundle 1 description	admin-facing	said "the shared Authelia login"

The button now points at authentik's public recovery flow, verified
reachable unauthenticated from outside Cloudflare and serving
ak-stage-identification under its Dutch title. This is not a hostname swap:
Authelia's /reset-password/step1 has no counterpart, the flow is the form.

The second fault was not part of this task and was already hurting members.
Step 41 told them to look for a mail with the subject "Corsarium: Reset your
password". authentik has not sent that since the branded Dutch mail landed at
6m; it sends "Stel het wachtwoord van je Corsarium-account in". Every member
who joined in between was sent hunting for a subject line that did not exist
while the real mail sat unread in front of them. Nothing measured this, which is
worth noting given the whole point of the 6f evidence gate.

Code, not database

scripts/lldap-sync-members.py had the same stale path baked into its "New
member never got their login mail" alert. That one is the nastiest of the set:
it fires exactly when somebody already has an account they cannot sign in to,
and after 6f it would have handed the operator a 404 at that precise moment.

The URL now resolves through recovery_page_url(), which follows wherever the
mail actually comes from: authentik's recovery flow once the portal variable is
set, Authelia's form while it is not, "the portal" if neither is. So 6f needs
no code change on the day.

Also checked, clean

• wizarr-nl-overrides.sh, wizarr-base-template.sh and nl/overrides.json
  contain no reference to the old portal.
• Only Plex is attached to any invite, so nothing else has quietly gone SSO
  and been left asking members for a password, the way Kavita did on 08-21.

Verification

• Database backed up first via SQLite's backup API (a file copy of a live DB can
  tear), written in one transaction, then read back from inside the container
  rather than trusted from the timestamp. Wizarr healthy throughout, ownership
  re-asserted to uid 99.
• Gotcha recorded in the doc: a SQLite write there leaves mtime untouched while
  ctime moves. restic keys on ctime so backups still catch it, but mtime is not
  a valid check that an edit landed.
• 3 new regression checks on recovery_page_url(), confirmed to fail when
  the fix is reverted. Suite 74 to 77.
• tests/run.sh green, zero failing suites.

Merge notes

• The 6e Status row is deliberately untouched. docs(identity): record the 6e forward-auth cutover as done #409 already corrects it and
  is green on all nine checks; this PR would only have collided with it. docs(identity): record the 6e forward-auth cutover as done #409 is
  unowned and should just be merged.
• Section 6f (evidence items 2, 3, 4) belongs to docs(identity): record 6f items 2 and 3, and how to test item 4 in minutes #412. No overlap: this PR only
  touches the 6f-pre section and the 6f-pre Status row.

Deploy: none required for the database half, which is already live on the
server. The script change ships with the next converge.