Task: Generate the schema fingerprint grant from its template

Regenerating the service grants keeps every service able to read the schema fingerprint.

• The db grants template emits the fingerprint grant for every service in the registry.
• Regenerating the grants from the registry changes nothing in the checked-in file.

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

The db grants template now emits the schema fingerprint grant for every service in the registry. #2574 had added it to the generated iam_service_db_grants_create.sql by hand, so regenerating the grants from the service registry, as any new service or grant change does, deleted it, and every service would then have refused to start for want of SELECT on ores_database_info_tbl. Regenerating the grants after this change leaves the checked-in file byte-for-byte as it was.