feat: declare the mappings field as a json-path-mapper

[jeffredodd]

What

Moves mappings onto core's capability-named widget, json-path-mapper,
and declares the two things core used to know about this plugin by name.

Core's mapping helper shipped as generic-data-mapping-helper — named after
this plugin — and it hardcoded our property names: it read url, format,
method, headers and body off the settings object, and printed the template
hint as {{generic_data.<var>}}. Core no longer knows any of that:

"ui:options": {
  "probe": { "url": "url", "format": "format", "method": "method",
             "headers": "headers", "body": "body" },
  "keys":  { "variable": "variable", "path": "path", "default": "default" }
}

Every value is the name the widget used to assume, so nothing changes for the
user — the same probe request, the same three inputs per row, the same stored
shape. They are declared now instead of assumed.

Core side: Fiestaboard/FiestaBoard#1557.

Blocked on core #1557 — read before merging

The fiestaboard_version floor here is >=8.25.5, which is a prediction, not
a fact. Core #1557 is not merged yet. FiestaBoard bumps a patch version per
merged PR (the PR is titled refactor(...), so pr-label gives it patch), and
main is on 8.25.4 — so 8.25.5 is right if #1557 is the next PR to land. If
anything else merges first, re-derive the floor from the release that actually
contains #1557 and update it here before merging this PR.

Nothing breaks if the order slips the other way. #1557 keeps
generic-data-mapping-helper as an accepted alias, so this repo was never
required to move in lockstep, and a core below the floor treats the new widget
name as a warning rather than a load failure (Fiestaboard/FiestaBoard#1554) —
the field just degrades to a plain array of objects. The floor exists so the
hourly plugin auto-update holds those boards on the manifest their core can
render properly, not because anything would break.

Version

1.2.2 → 1.3.0. No behaviour change, but the manifest now requires a core
capability it did not before, and the compatibility floor moves a long way
(>=4.2.0 → >=8.25.5).

TDD

All four tests were written first and observed RED before the manifest changed.

Test	Observed RED
mappings uses the capability-named widget	AssertionError: assert 'generic-data-mapping-helper' == 'json-path-mapper'
probe names this plugin's own request properties	KeyError: 'ui:options'
keys names the properties a mapping row actually has	KeyError: 'ui:options'
the core floor covers the widget this manifest asks for	AssertionError: >=4.2.0 predates json-path-mapper / assert (4, 2, 0) >= (8, 25, 5)

The probe and keys tests do not just compare literals — they also assert
that every property named on the right-hand side is actually declared in
settings_schema.properties and in mappings.items.properties respectively, so
renaming a settings property without updating the block fails here rather than
silently probing with that part missing.

Verification

• pytest tests/ — 75 passed before, 79 passed after (+4). Coverage gate
  (70%) unaffected; the new file is pure manifest assertions.
• Manifest checked against core main as it is today (no #1557):
  validate_manifest → valid: True, errors: [], with the single warning
  settings_schema.mappings: unknown ui:widget 'json-path-mapper' — the settings form will fall back to a plain input. It loads.
• Manifest checked against core with #1557: valid: True, errors: [],
  no warnings — probe and keys are recognised grammar, not unknown keys.
• json.loads round-trips the manifest.

feeds[].mappings is deliberately left alone: it has no ui:widget today and
renders as a plain nested array, which is unchanged by any of this.