Let pushes go by an HTTPS token or an SSH deploy key

The push credential is either a push-only account's token, handed to git
through a credential helper that names environment variables, never
values, or a deploy key in a short-lived ssh-agent. The remote URL
follows the credential. Configured as gitea.push_user and push_token, or
gitea.push_key.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE

docs/Development-Plan.md

@@ -354,8 +354,10 @@ if the implementation differs.
 - **D3 preflight:** a project's needs are read from its files (`Cargo.toml`,
   `pyproject.toml`, `package.json`) or a declaration in the repository.
 - **D4 publishing:** standard excludes are configured in each clone, and only what
-  the work produced is committed. A push hands the key over stdin to a
-  short-lived `ssh-agent` on the build VM, for that one push.
+  the work produced is committed. The push credential is handed to each push
+  only: a deploy key over stdin to a short-lived `ssh-agent` on the build VM, or
+  a push-only account's HTTPS token as that command's secrets, read by a
+  credential helper that names environment variables, never values.
 - **D7:** test services use ports 18000–18099, so opening access later is a
   firewall change. The inference host is behind LiteLLM, so it is not a second
   egress exception.