fix(actions): grant deploy.yaml contents:write so build-number action can push tag

[acedatacloud-dev]

Hotfix for #750. Production deploys have been failing since 05:17 UTC after the consolidation PR landed on main. This restores the deploy pipeline.

What broke

In #750 I added an explicit permissions: block to deploy.yaml to follow least-privilege practice:

permissions:
  contents: read
  packages: write   # for ghcr.io push

That broke the very first step of the workflow: einaregilsson/build-number@v2 tracks the monotonic build counter by creating a git ref refs/tags/build-number-NNN via the GitHub REST API. With contents: read the call gets:

##[error]Failed to create new build-number ref. Status: 403, err: null,
result: {"message":"Resource not accessible by integration",
         "documentation_url":"https://docs.github.com/rest/git/refs#create-a-reference",
         "status":"403"}

Failed run for reference: 25953665320 (deploy on merge commit a34575c4).

Result: every push to main since 05:17 UTC has failed the Generate Build Number step, which skips image build + k8s deploy. Production is still serving the previous image (build-number-760) until this lands.

What this PR does

One-line semantic change — contents: read → contents: write:

 permissions:
-  contents: read
+  # `contents: write` is required by einaregilsson/build-number@v2 — it
+  # creates a `build-number-NNN` git ref via the REST API to track the
+  # monotonic counter. Tightening to `read` here gives 403
+  # "Resource not accessible by integration" on the very first step.
+  contents: write
   packages: write # for ghcr.io push

This matches what the workflow was running under for years before #750 (the repo's default GITHUB_TOKEN permissions). The explicit block keeps everything else locked down (actions, issues, pull-requests, etc. all stay implicit-none).

Why not replace einaregilsson/build-number@v2

Considered. Replacing it (e.g. with a git rev-list --count HEAD style scheme, or actions/github-script writing the ref) is a bigger surgery that:

1. Changes the monotonically-increasing tag scheme that deploy/production/*.yaml depends on via ${TAG} substitution in deploy/run.sh.
2. Risks tag collisions if the build counter ever resets.
3. Doesn't actually need fixing here — the action works fine; it was my permissions block that broke it.

So: smallest fix that restores production. The action upgrade can be tackled separately if/when we want to drop the legacy ::set-env / ACTIONS_ALLOW_UNSECURE_COMMANDS requirement.

Verification

• python3 -c "import yaml; print(yaml.safe_load(open('.github/workflows/deploy.yaml'))['permissions'])" → {'contents': 'write', 'packages': 'write'} ✓
• Diff is +5/-1 (4 of those are clarifying comments) — only the permissions value changes.

Rollback

If this somehow makes deploys worse, revert is a 1-line edit back to contents: read — but that re-bricks the build counter. Cleaner rollback is git revert <this-PR-sha> which restores PR #750's broken state, so don't do that — just iterate forward.

---

This pull request was generated and committed by the GitHub Copilot coding agent on behalf of @CQUPTQiCu.