gitea: provision a ci-bot account with repo + branch-protection access

Workflows push as a dedicated ci-bot account rather than a human one, so its
PAT can be scoped, rotated and revoked on its own. Adding a repo to
`ciBotRepos` and redeploying is all it takes to grant access.

Collaborator access and branch-protection push-whitelisting exist only on
gitea's HTTP API — no CLI, no config-file surface — so this one part stays
imperative: a oneshot that PUT/PATCHes the API into the desired state. It
runs on deploys where the script changed, which means it won't self-heal a
revert done through the web UI unless the unit is restarted too.

Two secrets, deliberately distinct:
- gitea_provisioning_token is darman's own token (write:repository +
  write:user). Only an owner-scoped token clears reqOwnerCheck on the
  collaborator and branch-protection endpoints, and write:user is what lets
  it write the Actions secret below. ci-bot cannot grant itself access.
- gitea_ci_bot_token is ci-bot's push token, generated once by hand (the
  command is in the comment) and pushed into gitea as a user-level Actions
  secret CI_BOT_TOKEN. Gitea has no instance-wide secret scope, and every
  repo here is owned by darman directly rather than an org, so a user-level
  secret is the closest thing — repo-level lookups fall back to it.

Branch protection is applied to the default branch plus `develop`, since
version-bump.yml pushes there.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

hosts/jupiter/secrets.nix

@@ -42,4 +42,10 @@
   sops.templates."gitea-runner.env".content =
     "TOKEN=${config.sops.placeholder.gitea_runner_token}";
 
+  # provisioning access token for gitea used to setup ci-bot account + repo access
+  sops.secrets.gitea_provisioning_token.owner = "gitea";
+
+  # ci-bot access token to allow the ci-bot user to push to repos
+  sops.secrets.gitea_ci_bot_token.owner = "gitea";
+
 }