Drop the update that renames members named after their address

[JeroenDeDauw]

update.php renamed every member account the extension had not named, which is what members were
before it started minting names. One wiki has such accounts, a handful of test accounts that will be
removed and re-added through the admin panel instead, so the rename was complexity with no
deployment behind it.

The MemberAccess username reservation goes with it, since it existed only to keep a real account
from being there for the update to record its renames as, and so does the
memberaccess-opaque-name-reason message. Nothing else depended on the update: a member is found by
the address on the roster and their account by user id, so one still under an address-shaped name
logs in over either route, and the single sign-on shape check judges accounts being created rather
than existing ones.

Kept: opaque names for every account the extension creates, the minter, the refusal of a single
sign-on name the extension did not mint, and the renameuser log restriction, which predates the
update and covers renames performed by hand. update.php still creates the tables and adds the
mae_invited column.

A wiki that does carry member accounts named after an address is now left to remove those members
through the admin panel and add them again, which opens an account under a minted name.

Considered, omitted: a README note on that removal-and-re-adding, since no released version ever
named members after an address.

_{AI-authored — Claude Code, Opus 5 under Fable 5.1 (max); one-line ask from @JeroenDeDauw, no revisions; diff not yet human-reviewed; PHPCS and PHPStan level 9 clean locally against MediaWiki 1.43, PHPUnit left to CI.}

Production notes

Orchestrated by Fable 5.1 (max); the removal and this description were written by an Opus 5 subagent.

Verified locally: composer install, PHPCS over all 178 files, PHPStan level 9 with the MediaWiki
stubs resolved from a 1.43.6 checkout, and php -l on every changed file. Not verified locally:
PHPUnit and update.php, both of which need a MediaWiki install with a database; CI runs both.

Checked by reading rather than by running: that no login path depends on the removed update. The code
route finds a member through MemberRepository::findMemberByEmail and then their account by user id,
and SsoAuthorizationHandler's opaque-shape check sits behind !$user->isRegistered(), so a member
still under an address-shaped name is admitted by the roster on either route.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.61%. Comparing base (53cd26c) to head (b327ee5).

Additional details and impacted files

@@             Coverage Diff              @@
##             master      #35      +/-   ##
============================================
+ Coverage     86.58%   86.61%   +0.02%     
+ Complexity      677      655      -22     
============================================
  Files            75       74       -1     
  Lines          2378     2278     -100     
============================================
- Hits           2059     1973      -86     
+ Misses          319      305      -14     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[JeroenDeDauw]

This also unbreaks prowiki-docker's Dev Environment CI: ProAdmin's ExtensionUpdateRunner runs giveMembersOpaqueNames in-process on a wiki that does not load MemberAccess, where $wgMemberAccessReaderGroup is undefined, so PatchConfigApiTest errors 7 times against master/1.0.0 (https://github.com/ProfessionalWiki/prowiki-docker/pull/1973, reproduced locally). With this branch checked out the file passes. prowiki-docker and DockerWiki now pin ~1.0.0, so after merging, a 1.0.1 tag is what gets the fix there.

_{AI-authored — Claude Code, Fable 5.1 (max); posted unprompted while following up CI on @JeroenDeDauw's pin request; not human-reviewed; the reproduction and the fix check were run locally.}