The release workflow currently checks out github/cli.github.com using
a personal access token (SITE_DEPLOY_PAT) owned by an individual
maintainer to push generated docs, the index.html version stamp, and
RPM/DEB package metadata.

Replace that with a short-lived installation token minted at runtime
from the new gh-cli-site-deployer GitHub App, owned by the github
org and installed only on github/cli.github.com with Contents:write
permission. The App's credentials live in the production environment
as SITE_DEPLOY_APP_CLIENT_ID and SITE_DEPLOY_APP_PRIVATE_KEY,
federated from the github-cli Vault.

The token mint step is guarded on inputs.environment == 'production'
because non-production environments don't have the App credentials
and don't push to the site anyway (the Publish site step is already
gated on DO_PUBLISH which requires production). github/cli.github.com
is public, so the checkout in non-production falls back to
GITHUB_TOKEN for anonymous read access, matching existing behavior.

Also update docs/release-process-deep-dive.md to reflect the new
flow.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ploy

Fix workflow inputs for actions/create-github-app-token by replacing the incorrect app-id key with client-id in multiple deploy job steps. This corrects the parameter name (four occurrences) so the Action receives the expected secret (DEPLOY_APP_ID) and can generate deployment tokens successfully. No other changes to the workflow or action version were made.

Update .github/workflows/deployment.yml to rename the deploy secret from DEPLOY_APP_ID to DEPLOY_APP_CLIENT_ID and adjust all create-github-app-token steps to use the new secret (client-id: ${{ secrets.DEPLOY_APP_CLIENT_ID }}). This clarifies that the secret is the GitHub App Client ID used to generate deploy tokens and keeps the workflow consistent across multiple deploy-token job invocations.

Set `timeout-minutes: 20` for the Linux, macOS, and Windows deployment jobs in the deployment workflow to prevent stalled runs from hanging indefinitely.

Gate signing in sign.ps1 on a new DO_PUBLISH env var, set in the
deployment workflow to true only for production. This avoids attempting
code signing in non-production environments, consistent with the
existing DO_PUBLISH gating used elsewhere in the workflow.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>