Make apt publication use an internal runner and harden deploy-user setup

[cassi-volkova]

Summary

The first stable release using the new apt publication path exposed three deployment issues:

• The publication job ran on a GitHub-hosted runner, while the repository SSH endpoint is private-only. The connection timed out and correctly blocked the GitHub Release.
• On an organization self-hosted runner the endpoint was reachable, but OpenSSH rejected the forced-command deploy key because the service account was locked, had a non-login shell, and its authorized-key file was group-writable.
• After authentication was restored, the retention query printed the aptly command usage because the formatting option followed positional arguments. A same-version recovery also required forced overwrite of the already published pool file.

Reproduction

1. Push a stable semantic-version tag.
2. Wait for the Electron packages to finish.
3. Observe Publish apt repository fail before Create GitHub Release.

The original failure is visible in the 0.4.1 tag run. The package was ultimately published from an internal runner and the recovery run passed.

Expected result

A stable tag publishes the package, updates the signed repository indexes, applies per-package retention, and only then creates the GitHub Release.

Required repository changes

• Run the apt publication job on an organization self-hosted runner with repository-network access.
• Update the host setup instructions so the forced-command service account accepts public-key authentication while remaining password-inaccessible, and require owner-only permissions for its authorized-key file.
• Put the aptly output-format option before positional arguments in the retention query.
• Use forced overwrite when refreshing an existing package version so a failed publication can be recovered idempotently.
• Add a release-path check that catches these setup errors before the next stable tag.

No application runtime code is affected.