fix(ci): grant the tag workflow's release job the permissions release.yml declares

[TeddyHarnat]

What & why

The "Tag a Release" workflow_dispatch has never worked: run 33897671351 (its first-ever dispatch) died in 4s with startup_failure — no jobs, no logs. The cause is GitHub's reusable-workflow permissions cap: a workflow called via workflow_call cannot exceed its caller job's permissions grant. tag.yaml's release job granted only contents: write, while release.yml declares id-token: write and attestations: write for provenance attestation, so the dispatch fails validation at startup.

This never surfaced before because v0.3.0 was cut through the documented fallback — pushing the tag by hand — which triggers release.yml directly under its own top-level permissions.

Fix: grant the release job in tag.yaml the same three permissions release.yml declares, with a comment explaining the subset rule so the next permission added to release.yml gets mirrored.

Checklist

• bazel test //flutter/tests:all_tests //docs:update_tests passes — not run: CI-workflow-only change, no Bazel targets affected
• cd e2e/smoke && bazel test //:integration_tests passes (if behavior changed) — no build behavior change
• Ran bazel run //docs:update if any rule/macro API changed — no API change
• pre-commit run --all-files (buildifier + prettier) — actionlint passes on the edited workflow; no Starlark touched
• Updated docs/README for user-facing changes — comment added at the fix site