[3.0][Testing] Install the forum from the command line

[albertlast]

Description

The dev environment from #9317 stops at a generated Settings.php and a staged
install.php, leaving the install itself to a human clicking through a browser.
That is the one step between a fresh clone and a running forum that could not be
scripted, and everything that wants to test against a real install has to start
by doing it.

This makes it one command:

.docker/install-forum.sh --engine mysql
.docker/install-forum.sh --engine both

Four scripts under .docker/: install-forum.sh, use-engine.sh, reset.sh,
and a sourced lib.sh. Nothing ships with the forum — .docker/ is already
skipped by check-smf-index.php and check-smf-license.php.

The installer turned out to be almost there already: parseCliArguments() turns
--name=value into $_POST and execute() runs every step in one process. So
this needs two passes rather than the five curl requests 2.1 needs. The second
carries pop_done, which is the short-circuit past the population report;
passing it on the first pass would skip building the schema entirely.

--engine both installs MySQL and then PostgreSQL, sequentially — Settings.php
pins one $db_type and Db::load() hands back the connection it already made,
so only one engine is ever live in a process. Both installs are kept, and
use-engine.sh switches between them without reinstalling.

The five installer fixes this needed

Each of these only bites without a browser, so none could be worked around from
outside. Four are CLI-only; the last one is wrong in the browser too.

1. Nothing was ever reported. Maintenance::exit() renders the tool's
   templates, and those are the only place errors are shown. On the command line
   it takes the fallthrough path straight to die(), so a scripted install that
   died on step three looked exactly like one that finished — no message, exit
   status 0. ToolsBase::updateSettingsFile() made the same assumption more
   directly, calling die() outright rather than recording the error.
2. forumSettings() was fatal. It built a suggested board URL with
   substr($self, 0, strrpos($self, '/')). getSelf() is $_SERVER['PHP_SELF'],
   which on the command line is usually a bare install.php with no directory in
   it, so strrpos() returns false and substr() throws on PHP 8.
3. defaultHost() read $_SERVER['SERVER_NAME'] and ['SERVER_PORT']
   unguarded, so every run opened with an undefined index warning.
4. finalize() signed a browser in, setting a login cookie and recording a
   session against the user agent that asked for it. With no browser that is four
   warnings — headers sent after output started, a session that could not start,
   an id that could not be regenerated — and a sessions row built from an
   undefined HTTP_USER_AGENT.
5. An unrecognised database type reported nothing. It used
   Lang::getTxt('upgrade_unknown_error'), which is not a string that exists, so
   the fatal error was blank in the browser as well. Now names the type that was
   rejected and the ones that would have been accepted — which matters most on
   the command line, where the type is typed by hand rather than picked from a
   list of exactly those keys. (They are capitalised: MySQL, PostgreSQL.)

Verified

Installed from scratch on both engines, from the tree in this branch:

• .docker/install-forum.sh --engine both --pin-secrets --force completes clean,
  no warnings, exit 0.
• Both forums serve 200 on the board index, login, help, recent, stats and
  credits.
• check-signed-off.php, check-smf-index.php, check-smf-license.php and
  check-smf-languages.php all pass; shellcheck is clean on all four scripts.

Not addressed here, because it is not CLI-specific: a fresh install logs five
undefined_vars errors for latestMember / latestRealName, because
finalize() loads the theme before Logging::updateStats('member') runs. The
values are correct once installed, and browsing afterwards is clean.

Merge order

Merge #9317 and #9316 before this one. Both are contained in this branch, so the
diff shown here is theirs as well as its own; once they land and this is rebased on
release-3.0, what is left is the install script and the installer fixes it needed.

Issues References (Fixes|Related|Closes)

1. Depends on [3.0][Testing] Add a Docker development environment for MySQL and PostgreSQL #9317 — this builds on .docker/ and compose.yaml.
2. Depends on [3.0] Load the current user before finalize() records dates #9316 — merged in here, or the install dies on its last step.

[live627]

looks like all dependencies are merged. can we merge this one now?