[3.0] Stop the current board being rebuilt into an empty object

[albertlast]

Description

Noticed while testing #9432. Any page that has a current board and then walks the
board tree is a 500:

?action=search;board=1.0
?action=search;topic=1
?action=admin;area=manageboards;board=1.0

Typed property SMF\Board::$id must not be accessed before initialization

Category::getTree() rebuilds each board from the row it has just read, and to
do that it drops the old object first:

unset(Board::$loaded[(int) $row['id_board']]);
Board::init((int) $row['id_board'], $row);

For every board but one that is fine. For the board the member is actually on,
Board::init() finds nothing loaded and constructs a new object — and the
constructor sees an id equal to Board::$board_id, takes its "load the current
board" path, finds Board::$info already set, and returns having assigned
nothing at all:

if (!isset($id) || (!empty($id) && $id === self::$board_id)) {
    // Only do this once.
    if (!isset(self::$info)) {
        …                       // ← everything, including $this->id, is in here
    }
} else {
    …
    $this->id = $id;
    $this->set($props);
    self::$loaded[$this->id] = $this;
}

// Add this board as a child of its parent.
if (!empty($this->parent)) {          // ← reached either way

What comes back is an object with no id, no name and no anything, and the tail of
the constructor reads $this->id immediately.

The fix

The board is not really gone — Board::$info is still holding it. So put that one
back rather than building a second object claiming to be the same board, and let
the existing branch below apply the fresh row to it. getTree() then finds
Board::$loaded[$id] where it expects it, and the tree it builds refers to the
same instance as the rest of the request rather than to a copy.

The new branch only fires when Board::$info is set, the id is the current board,
and that board is missing from the loaded list — the exact combination that
used to throw. Every other path through init() is untouched.

Testing

Swept 22 pages as an admin, with the current board set to a top level board and
then to a child board (so the parent/child branch of the constructor is
exercised too):

• the three URLs above load;
• every page that already worked still does;
• the board trees on Manage Boards, the search board picker and Manage
  Permissions come out identical to release-3.0 — compared by fingerprinting
  every board input, board link and category name on each page;
• the error log is clean afterwards, apart from the known calendar
  TimeInterval fault ([3.0] Calendar 500s on any forum with an event: SMF\TimeInterval is not a usable \DateInterval #9384, fixed by [3.0] Let SMF\Time do arithmetic with an SMF\TimeInterval #9405).

Issues References (Fixes|Related|Closes)

Related to #7933