[3.0] Load the current user before finalize() records dates

[albertlast]

Note

This change was produced by an LLM. The code, the commit message and this
description were all written by Claude (Anthropic), driven by @albertlast. It has
not yet had human code review.

Everything stated below was verified by actually running it against a fresh
PostgreSQL install of this branch, rather than only reasoned about. Even so,
please review it as untrusted work: the diagnosis may be right while the fix is
not what SMF would prefer stylistically or architecturally.

Description

Install::finalize() calls Time::strftime() to build the log_activity date, and a
little later Logging::updateStats(), which does the same thing. Both end up in
Time::__construct(), which reads User::$me to resolve the time zone:

if (!isset(self::$user_tz)) {
    self::$user_tz = TimeZone::create(User::$me->timezone);
}

But User::setMe() / User::loadMe() are not called until roughly a hundred lines
further down the same method, so installation dies on its final step:

Error: Typed static property SMF\User::$me must not be accessed before
initialization in Sources/Time.php:191
  #1 Sources/Maintenance/Tools/Install.php(1151): SMF\Time::strftime('%Y-%m-%d', ...)
  #2 Sources/Maintenance/Maintenance.php(298): ...->finalize()

The installer aborts at step 7 of 7, after the schema and the admin account have been
created, so the forum looks installed but finalize() never ran. Everything it is
responsible for is missing, including latestMember and latestRealName, which then
produce their own warnings on the board index.

This moves the user initialisation up to just after the settings are reloaded, which
is the first point at which it can run, and leaves the rest of the "we've just
installed" block where it was.

Worth noting: fixing only the strftime() call would not have been enough, because
Logging::updateStats() reaches the same code via Sources/Logging.php:466 a few
lines later and would have failed identically.

How this was verified

Full install from an empty database, PostgreSQL 17 / PHP 8.4:

• Before: fatal at step 7; latestMember, totalMembers, totalTopics,
  totalMessages all absent; no log_activity row.
• After: reaches step 7 at 100%, writes the log_activity row that previously
  crashed, sets all four settings, and logs zero errors across the whole install.

⚠️ Merge conflict with #9302

This conflicts with #9302 ("[3.0] Upgrader login fixes"), which is actively
refactoring the same method. I test-merged them to confirm rather than guessing:
Sources/Maintenance/Tools/Install.php conflicts.

The conflict is purely textual. #9302 rewrites Maintenance::$context to
Utils::$context throughout finalize(), including the lines immediately around
where this patch inserts. It does not fix this bug — every one of its hunks in
finalize() is that rename, the strftime() call stays at line 1151 and the
setMe()/loadMe() block stays ~100 lines below it.

Since #9302 is already touching this method, folding the reordering into it may be
tidier than merging both. Happy to rebase this onto #9302, or to close it if that is
the preferred route. The other PRs in this batch all merge onto #9302 cleanly; this is
the only one that does not.

Issues References (Fixes|Related|Closes)

1. Related: [3.0] Upgrader login fixes #9302 (conflicts, see above)