fix: a data attribute is escaped like everything else the theme renders

[blaipr]

Eight places in four templates emitted data-<name>="<value>" out of a
DataGridAction::getData() / getRuntimeData() map with no escaping at all — not $_e(), not
anything:

printf('data-%s="%s"', $dataName, $dataValue);
echo 'data-', $dataName, '=', '"', $dataValue, '"';

Nothing is leaking today: every current addData()/setRuntimeData() call passes an ACL route
string or an integer id. The one value that is not a literal is FileGrid's item-type, a MIME type
that AllowedMimeType::resolve() requires to match the administrator's own allow-list exactly, so
putting a quote there is self-inflicted.

But nothing in the templates or in DataGridActionBase constrains what a caller may pass, and one
addData() carrying a name, a login or a note breaks straight out of the attribute. data-onclick
was unescaped the same way.

Why the existing guard could not see it

ThemeEscapesWhatItRendersTest decides what carries text by the getter's name (getName,
getLogin, …) or by $_getvar(. A bare $dataValue in a loop matches neither, so the rule that
holds the rest of the theme to escaping-on-output had a blind spot exactly where a caller-supplied
map is rendered.

aDataAttributeMapIsEscaped() closes it, narrowly: it looks only at the loops whose attribute
name is itself a variable — which are precisely the ones taking an arbitrary map — and requires
$_e( in the emitting expression. A fixed data-item-id="<?php echo $id; ?>" is an id by
construction and stays with the rule above.

Writing the guard found more than the audit did

The review that started this named three sites, in datagrid-rows.inc and search-rows.inc. The
guard, run against the source, found five more: two in _partials/fixed-header.inc and three in
grid/datagrid-grid.inc. That is the whole argument for scanning rather than fixing a list.

Tests

Mutation-verified: reverting public/ fails the guard on four templates, naming all sixteen
occurrences.