Name the columns in the fogstorage grant probe, so a schema step stops breaking it

[mastacontrola]

Regression from #1208. An upgrade on a server whose grants are perfectly
correct now stops and demands the database root password:

* Granting access to fogstorage database user.................
  To improve the overall security the installer will restrict
  permissions for the *fogstorage* database user.
  Please provide the database *root* user password.

Nothing is wrong with the grants. installFOGDB()'s probe writes a throwaway
row as fogstorage to find out whether that user still holds INSERT, and reads
ANY failure as "the grants need redoing". The probe was a positional INSERT:

INSERT INTO taskLog VALUES ( 0, 0, 3, '127.0.0.1', NOW(), 'fog-install-probe');

#1208 added logType and logText, taking taskLog from six columns to eight, so
that statement is now error 1136, "Column count doesn't match value count".
The grants are untouched -- reaching a column-count error means the connection
and the INSERT privilege both worked, which is exactly what the probe was
asking about.

THE SECOND TIME. Schema 336 made taskID the int(11) it always held, and the
marker '999test' in that column became error 1265 under STRICT_TRANS_TABLES.
Same prompt, same misleading symptom. That was repaired by moving the marker
into createdBy -- which fixed the instance and left the positional list, so
the next ADD COLUMN reopened it. Naming the columns is the repair that holds:
a column added later takes its default and the INSERT does not care.

VERIFIED on a live 1.6 server at schema 338, both statements run as fogstorage
inside a transaction and rolled back so nothing persisted:

positional  -> ERROR 1136 (21S01): Column count doesn't match value count
named       -> ROW_COUNT() = 1

tests/installer-db-probes-name-columns.test.php fails on any positional INSERT
anywhere in the installer, not just this one, and separately on the probe
losing its column list or disappearing. Mutation-verified against the bug
exactly as shipped, against a new positional INSERT elsewhere, and against the
probe being deleted.

1.5 is deliberately not touched. dev-branch's copy is positional too, but its
taskLog still has the six columns that statement was written for and 1.5 is
not gaining any, so there is nothing broken there to fix.

Why a Normal Server needs a fogstorage user at all

Worth stating, because the prompt makes it look like the installer is asking
for a storage node's credential on a machine that has no storage node.

It isn't. The password being asked for is the database root password, and
the account being repaired is fogstorage — a deliberately unprivileged
database user with SELECT on the schema and INSERT/UPDATE on the eleven
tables imaging actually writes. A Normal Server is its own master storage
node, so the node-side code paths run here and authenticate as that user; the
point of it is that the credential sitting in a node's config cannot drop
tables or read the user table.

So the account is real and the grants are wanted. What was wrong was only the
probe that decides whether they need rebuilding.

🤖 Generated with Claude Code

https://claude.ai/code/session_013mJVe4CpK3rRbi9H5GubXd