fix(ci): declare permissions on every caller template and own workflow

[andrew2net]

Closes the fleet-wide CodeQL actions/missing-workflow-permissions alert (medium). Found via the security-bot review on relaton-data-jcgm#1.

Why it has to be fixed here

The alert is open on deploy.yml, crawler.yml and check_data.yml in at least seven relaton-data-* repos (jcgm, iana, iso, ieee, iec, ids, iho), plus this repo's own ci-lint, ci-spec and ci-repo-watcher.

It cannot be fixed where it is flagged:

• Not in the data repos — every flagged file is Cimas-generated, so a hand-edit is reverted by the next cimas sync.
• Not in the reusable workflows — a called workflow's permissions: can only downgrade what the caller granted. CodeQL knows this and deliberately skips workflow_call-only workflows, which is why relaton/support's own crawler.yml and check-data.yml are not flagged despite declaring nothing.

So the grant goes on the caller templates, which live here.

The trap: each grant is a union, not a minimum

A caller must grant the union of every scope every job of the called workflow requests — not the narrowest set describing what the caller itself does.

This matters most for deploy.yml. data-deploy.yml declares contents: read at workflow level and adds pages: write + id-token: write on its deploy job. A reflexive "minimal permissions" edit to contents: read does not fail at parse time — it fails minutes into the build, at the deploy step, in all 29 data repos at once:

The workflow is requesting 'pages: write', but is only allowed 'pages: none'.

Every grant below was verified by reading the called workflow, including the upstream metanorma/ci ones.

Caller	Grant	Because the called workflow…
data/deploy.yml	contents: read, pages: write, id-token: write	data-deploy.yml declares contents: read (workflow) + pages/id-token: write (deploy job)
data/crawler.yml	contents: write	crawler.yml's "Push data" step runs git commit + git push with checkout's persisted GITHUB_TOKEN
data/check_data.yml	contents: read	checkout + bundle exec ruby check_data.rb
master/release.yml	id-token/contents/packages: write	matches what support/release.yml declares (see caveat)
model/make.yml	contents: read	checkout + bundle exec make clean all
master/rake.yml	unchanged	already had workflow-level contents: write
ci-lint.yml	contents: read	metanorma/cici-lint.yml declares contents: read
ci-spec.yml	contents: read	checkout + rspec
ci-repo-watcher.yml	contents: read, issues: write	metanorma/cici-repo-watcher.yml declares both and opens/updates an issue via comment-or-create

ci-repo-watcher was the one worth reading rather than guessing: too narrow means a silent daily-cron failure nobody watches.

Also: the keep-alive template had drifted

master/keep-alive.yml was three regressions behind what every data repo carries by hand — and none of them were visible in CI:

1. Missing permissions: actions: write. A sync would have reopened a CodeQL alert that currently reads fixed in six repos.
2. Missing workflow_dispatch:, leaving a monthly cron as the only trigger — precisely the workflow GitHub disables for inactivity, with no way back in.
3. uses: still pointing at metanorma/ci, which no longer has a keep-alive.yml at all. The target was already a 404.

It now diffs functionally clean against the deployed relaton-data-iana copy, so that sync is a no-op.

Known over-grant, deliberately left

packages: write on the release caller. Nothing downstream requests it — metanorma/ci's rubygems-release.yml grants its jobs only contents + id-token, and publishing goes to RubyGems, not GitHub Packages. It is here only because support/release.yml declares it, and removing it from the caller alone would cap that file below its own declaration. Removing it means editing both files in one change, verified against a live release. Documented in place; flagged for follow-up rather than smuggled into this PR.

Tests

spec/workflow_permissions_spec.rb (new) encodes the CodeQL rule itself so the class stays closed rather than these instances being fixed once:

• every Cimas-synced caller template declares a non-empty grant (list derived from cimas.yml, not globbed);
• every workflow this repo runs itself does too, skipping exactly the workflow_call-only set CodeQL skips;
• exact-value pins for each template's grant, so a future narrowing fails here rather than in production;
• the three keep-alive regressions, pinned individually.

spec/data_deploy_caller_template_spec.rb gains the deploy/crawler union assertions, sitting next to the existing block that asserts what that job must not carry.

333 examples, 0 failures.

Verification still outstanding

The only thing that truly proves the union was right needs credentials:

1. cimas sync -g data and confirm the diff in one data repo is only the added permissions: blocks.
2. On the first repo synced, trigger Deploy via workflow_dispatch and confirm the deploy job publishes rather than failing the pages: none check.

Related, not touched

• feat/data-check-index-caller adds a new check-index.yml template with no permissions: block — the new sweep will fail on it when those branches meet.
• data/check_data.yml's push branches are [ master, main ], but all three repos it syncs into (bipm, iho, iso) are on v2, so its push trigger never fires. Pre-existing, out of scope.