ci: publish codex-app-server release artifacts (#19447)

## Why
The VS Code extension and desktop app do not need the full TUI binary,
and `codex-app-server` is materially smaller than standalone `codex`. We
still want to publish it as an official release artifact, but building
it by tacking another `--bin` onto the existing release `cargo build`
invocations would lengthen those jobs.

This change keeps `codex-app-server` on its own release bundle so it can
build in parallel with the existing `codex` and helper bundles.

## What changed
- Made `.github/workflows/rust-release.yml` bundle-aware so each macOS
and Linux MUSL target now builds either the existing `primary` bundle
(`codex` and `codex-responses-api-proxy`) or a standalone `app-server`
bundle (`codex-app-server`).
- Preserved the historical artifact names for the primary macOS/Linux
bundles so `scripts/stage_npm_packages.py` and
`codex-cli/scripts/install_native_deps.py` continue to find release
assets under the paths they already expect, while giving the new
app-server artifacts distinct names.
- Added a matching `app-server` bundle to
`.github/workflows/rust-release-windows.yml`, and updated the final
Windows packaging job to download, sign, stage, and archive
`codex-app-server.exe` alongside the existing release binaries.
- Generalized the shared signing actions in
`.github/actions/linux-code-sign/action.yml`,
`.github/actions/macos-code-sign/action.yml`, and
`.github/actions/windows-code-sign/action.yml` so each workflow row
declares its binaries once and reuses that list for build, signing, and
staging.
- Added `codex-app-server` to `.github/dotslash-config.json` so releases
also publish a generated DotSlash manifest for the standalone app-server
binary.
- Kept the macOS DMG focused on the existing `primary` bundle;
`codex-app-server` ships as the regular standalone archives and DotSlash
manifest.

## Verification
- Parsed the modified workflow and action YAML files locally with
`python3` + `yaml.safe_load(...)`.
- Parsed `.github/dotslash-config.json` locally with `python3` +
`json.loads(...)`.
- Reviewed the resulting release matrices, artifact names, and packaging
paths to confirm that `codex-app-server` is built separately on macOS,
Linux MUSL, and Windows, while the existing npm staging and Windows
`codex` zip bundling contracts remain intact.

.github/actions/windows-code-sign/action.yml

@@ -4,6 +4,9 @@ inputs:
   target:
     description: Target triple for the artifacts to sign.
     required: true
+  binaries:
+    description: Space-delimited binary basenames to sign.
+    default: "codex codex-responses-api-proxy codex-windows-sandbox-setup codex-command-runner"
   client-id:
     description: Azure Trusted Signing client ID.
     required: true
@@ -33,6 +36,23 @@ runs:
         tenant-id: ${{ inputs.tenant-id }}
         subscription-id: ${{ inputs.subscription-id }}
 
+    - name: Prepare file list
+      id: prepare
+      shell: bash
+      env:
+        TARGET: ${{ inputs.target }}
+        BINARIES: ${{ inputs.binaries }}
+      run: |
+        set -euo pipefail
+
+        {
+          echo "files<<EOF"
+          for binary in ${BINARIES}; do
+            echo "${GITHUB_WORKSPACE}/codex-rs/target/${TARGET}/release/${binary}.exe"
+          done
+          echo "EOF"
+        } >> "$GITHUB_OUTPUT"
+
     - name: Sign Windows binaries with Azure Trusted Signing
       uses: azure/trusted-signing-action@1d365fec12862c4aa68fcac418143d73f0cea293 # v0
       with:
@@ -50,8 +70,4 @@ runs:
         exclude-azure-developer-cli-credential: true
         exclude-interactive-browser-credential: true
         cache-dependencies: false
-        files: |
-          ${{ github.workspace }}/codex-rs/target/${{ inputs.target }}/release/codex.exe
-          ${{ github.workspace }}/codex-rs/target/${{ inputs.target }}/release/codex-responses-api-proxy.exe
-          ${{ github.workspace }}/codex-rs/target/${{ inputs.target }}/release/codex-windows-sandbox-setup.exe
-          ${{ github.workspace }}/codex-rs/target/${{ inputs.target }}/release/codex-command-runner.exe
+        files: ${{ steps.prepare.outputs.files }}