[3.0] Pass logBan() its row in the structure insert() expects

[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

Db::$db->insert() takes a multidimensional array, one entry per row, and rejects
anything else:

Invalid data structure sent to the database.<br>Function: logBan

Logging::logBan() passed a single flat row:

[
    $id ?? User::$me->id,
    $ip_address ?? User::$me->ip,
    $email ?? User::$me->email,
    time(),
],

Forums running with $backward_compatibility enabled never notice, because
SMF\Db\APIs\PostgreSQL::insert() (and the MySQL equivalent) quietly wrap the row
for them. That setting is 0 by default, so on a new install every ban hit logged a
critical error, no row was written to log_banned, the ban item hit counter never
incremented, and the member got an error page rather than the ban message.

This wraps the row so it is a list of rows, matching every other caller.

How this was verified

With a real cannot_access ban in place, on PostgreSQL 17 / PHP 8.4:

• Before: smf_log_banned empty, smf_ban_items.hits stayed 0, one critical error
  logged per request.
• After: three requests produced three smf_log_banned rows with the correct IP,
  hits incremented to 3, and no errors logged.

Relationship to other PRs

Only reachable once bans work, so best reviewed with #9310 and #9311. Merges cleanly
alongside both; they touch different files.

Issues References (Fixes|Related|Closes)

1. Related: [3.0] Only enforce bans that actually exist #9310, [3.0] Clear the topic and board statics instead of unsetting them #9311