secrets: rotate gitea_luna_token with the issue scope

The previous token was write:repository only, which clones, fetches and
pushes branches perfectly well and then fails at `tea pr create` — a pull
request is an issue in gitea's data model, so every /pulls endpoint gates on
the issue scope category rather than the repository one.

Regenerated with write:repository,write:issue,read:user. Confirmed against
the running instance: gitea reports the granted set as
  read:activitypub, read:misc, read:notification, read:organization,
  read:package, write:issue, write:repository, read:user
so write:issue is present rather than only read:issue, which would satisfy
the GET half and still fail the POST that opens the PR. The extra read:*
categories are gitea expanding the request, not something asked for.

No manual step on mars: gitea_luna_token already restarts
hermes-agent-prepare-dirs, which does delete-then-add for the tea login on
every start and so picks up the rotation by itself.

The old token is NOT revoked — gitea's CLI cannot delete tokens and the API
route needs basic auth as luna, which nothing here sets. It stays valid until
removed by hand.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S94o42aQ8VkBmEWvDem5xa

secrets/mars.yaml

@@ -4,7 +4,7 @@ tailscale_authkey: ENC[AES256_GCM,data:An+OPDZF9kmemzoDhZPo7yMljksCz3yE/W9I1EAwt
 opencode_go_api_key: ENC[AES256_GCM,data:x7V6iRrP6UMvMAYh/25bcrE10MHhL9lasCYRHiQ3PIDI6aL+uXP0/YpfrRPY+60m5Yv+Bd7+9aWTWdAVu1laSNjJGg==,iv:EmEAig+fSMYX+g77UpkiQ0USxUYOfFWX4WjIj9NA9N8=,tag:Pr+EZW6uDTSGjng8iG2SZw==,type:str]
 telegram_bot_token: ENC[AES256_GCM,data:WX+KFtoqFodkoWNwd7EXUrUJakZ9oaMZgg4OnCeL/JVXcsdQesD1PLmKp6vK9g==,iv:m1oqKlcesvhMLtndyp/XxsUAy0YpEsSulPDK0V+Wh0A=,tag:zvLcxcQ+A4fQUht5GkL2Qw==,type:str]
 hermes_dashboard_oidc_client_secret: ENC[AES256_GCM,data:IMPNTPMKO+b7eyV4hyGfnvH1/i+W4IPDNjncoyB1oIV8WaB6nOJn0sSEuTUCKB94K+Y7bsVQU0zpbKdIYOdGqgmPzwMCsScxMt4SewTmiiqWxv6SQFf4EzMxgXqjMvH8PWDzLcI2C2tI/KcVS251iqRViOTFe1/tkm+mV8sJmEI=,iv:F/rOUDmJZoGPS9fObAni5ntyOqbbhMWDPdHGLTexwlA=,tag:ALf98DmB0JziGspZMiLCiw==,type:str]
-gitea_luna_token: ENC[AES256_GCM,data:EgSgzXFlYHN1yAlpjBBjSxacVYO9mhe1TBtAjNMZDEPxkeizB5O8Bw==,iv:pKN6bz7mBV3HxqBdnJi6ah17bukhd+sXeItojngT0HE=,tag:1wCfPK+MJb+P/S/kq2czeQ==,type:str]
+gitea_luna_token: ENC[AES256_GCM,data:0ypW9oVFs1mXYPhPareMFRdkSYcvHSCm+fQOd7/76lJEXi217r9dmg==,iv:j3TPm/iLk6pB6CmDePFBOlnhxWSbmLKvOhz06SM1T7k=,tag:ydErvC2mZ1RRnwNffiHkkg==,type:str]
 gitea_hermes_webhook_secret: ENC[AES256_GCM,data:lV78H0xAehPxusSO/QruOYkt7fkMJrW+ScZL4UWYvgnBGn/D+1XHYPyHCqe2sEEWSlIaAgWMMoZzoVJ1Z1NFVQ==,iv:GmTZxoH2iiL/vTVgPfziXIFYD+Rl3cbh9hqXvWps+iw=,tag:jtXEUOVFfKrpTRK7S9PZMA==,type:str]
 sops:
     age:
@@ -26,7 +26,7 @@ sops:
             oyJ7PS3lW+PxH5AZkeeU7gXO/pz2oDku0aDOds7kaD3n0+qSWicQ+Q==
             -----END AGE ENCRYPTED FILE-----
           recipient: age1eapjg6tdrr0fuvmgs3q3nlvnjkaxez298qynqqqxt0lpcv0lrsyq7ayxjk
-    lastmodified: "2026-08-23T03:16:52Z"
+    lastmodified: "2026-08-23T05:55:49Z"
-    mac: ENC[AES256_GCM,data:ALMAmzwnr7JZ6gpO7De0d/60n52/GYWZjmsiZ9mlXbxgaYIu+nTguthCo+Loc88oUU3dy8tzj6prmrYDbUcfkg2pfrcpHoSxxTwoTvljL+1yS37682KgLW9KBHPFN2JMx02uho5EWPQp9jiSJZltfyxbLlPV8T5TJnsrtEeAR2Y=,iv:j7qHt+/KOlF+qhcj3FPYR9MTklTXvLGExzTQ6YHT89I=,tag:bUIdLGBO48+8kFsrel2O8w==,type:str]
+    mac: ENC[AES256_GCM,data:a3vCmrQMCS25tNWrzTeiGmOHf4Fn356PO3uNa2HvS21EBCKTc6YWBj9KmpORdz+6t03JJe/4eiGdghGaLhRr+JXyQnaT54gSV+FhC3dH6blind746XN3h+Z9rxiva6apvcAGUZ9k01Js5IXN9efEMhcI6w0U4oVuVqtvShvg8A8=,iv:9kF3cJ1vyy2H3eH10DVCYmWeXv2MH4AFDiF8cOajlw4=,tag:zhombLVpL8M1TUtYur/gYQ==,type:str]
     unencrypted_suffix: _unencrypted
     version: 3.13.3

services/dev/gitea.nix

@@ -77,6 +77,23 @@ in
       service = {
         DISABLE_REGISTRATION = true;
       };
+      security = {
+        # Gitea refuses to deliver a webhook to any host outside this list,
+        # which defaults to `external` — "a valid non-private unicast IP".
+        # Tailscale addresses are 100.64.0.0/10 (RFC 6598 carrier-grade NAT),
+        # which is neither RFC1918 private nor, as far as gitea's matcher is
+        # concerned, external — so the hermes relay on mars was refused with
+        #   deny 'mars.orbit.sol(100.64.0.6:8645)'
+        # even though nothing here is private in the RFC1918 sense. Adding
+        # the tailnet CIDR is what makes tailnet-internal webhook targets
+        # deliverable at all; `external` is kept so a future webhook to a
+        # public service (discord, slack) still works without another edit.
+        #
+        # This lives in [security], not [webhook]: the webhook-section key is
+        # deprecated and now just falls back to this one, which is the name
+        # the delivery error itself reports.
+        ALLOWED_HOST_LIST = "external,100.64.0.0/10";
+      };
       actions = {
         ENABLED = true;
       };
@@ -85,6 +102,24 @@ in
 
   networking.firewall.allowedTCPPorts = [ 2222 ];
 
+  # `gitea <args>` == the admin CLI, as the gitea user, against the real
+  # state dir — mirrors the `hermes` alias on mars. Worth having because none
+  # of that is discoverable: the package is not in systemPackages (so `gitea`
+  # is not otherwise on PATH at all), every admin subcommand needs
+  # GITEA_WORK_DIR pointed at a stateDir that is not the module default, and
+  # it has to run as the gitea user or it writes root-owned files into that
+  # directory. Both paths come from the config rather than being spelled out,
+  # so a package bump or a stateDir move cannot leave this stale.
+  #
+  # Handy ones:
+  #   gitea admin user generate-access-token --username luna \
+  #     --token-name luna-$(date +%Y%m%d) \
+  #     --scopes write:repository,write:issue,read:user --raw
+  #   gitea admin user list
+  #   gitea actions generate-runner-token
+  programs.zsh.shellAliases.gitea =
+    "sudo -u ${config.services.gitea.user} env GITEA_WORK_DIR=${config.services.gitea.stateDir} ${config.services.gitea.package}/bin/gitea";
+
   users.users.gitea.extraGroups = [ "users" ];
 
   # Runner instance registered against this same gitea. Jobs run in containers