ci(release): enable gcp-secret-manager feature for gravity_node (#713)

## Summary

The `Release` workflow in PR #710 builds `gravity_node` with `default =
[]` features, so the released v1.6.0 binary (commit `e8594e7b`) panics
on every Staging Mainnet node whose identity is sourced from GCP Secret
Manager:

\`\`\`
panicked at .../config/network_config.rs:281:25:
load identity blob for peer_id from GCP secret
projects/mainnet-storage/secrets/staging-vfn-1-identity/versions/latest:
GCP Secret Manager support not compiled in. Rebuild aptos-config with
\`--features gcp-secret-manager\` (or enable the forwarding feature on
the
downstream crate, e.g. \`gaptos/gcp-secret-manager\`).
\`\`\`

Observed live on `vfn-1` and `vfn-2` after the v1.6.0 rollout
(2026-05-13 ~15:37 UTC): both had `NRestarts > 2700`,
`ActiveState=activating / auto-restart`, every ~5s, with the panic above
logged in `journalctl`. \`core-1..4 / rpc-1\` showed the same v1.6.0
binary on disk but had not yet started (separate \`/data\` / unit
ordering issue — not in this PR's scope).

## Fix

Split the build step. \`gravity_node\` is now built with:

\`\`\`bash
cargo build --profile quick-release -p gravity_node --bin gravity_node
--features gcp-secret-manager
\`\`\`

\`gravity_cli\` is built in its own step (the feature is declared
per-package on \`bin/gravity_node/Cargo.toml\`; cargo's workspace-level
\`--features\` would not resolve it for the combined multi-bin build).

## Test plan

- [x] PR-trigger dry-run (this PR) — confirm both \`Build gravity_node\`
and \`Build gravity_cli\` steps succeed and the resulting binary is
uploaded as \`release-dryrun-<sha>\` artifact.
- [x] Local build on LA Private Mainnet build host
(\`gravity-mainnet-node-la-0\`, Debian 11, rustc/cargo 1.93.0 matching
\`rust-toolchain.toml\`) using the same cargo invocation: succeeded in
**3m 15s**, sha256
\`921dd5bfc8ee11ba0360c5343f105b579d2e3aed17ef29b7ab02513cdf6d278d\`.
(LA artifact dynamic-links \`libssl.so.1.1\` so it's only usable on
Debian 11 / Private Mainnet, but this validates that the cargo
invocation works and gravity_node compiles cleanly with the feature on.)
- [ ] After merge: cut a new release tag (e.g.
\`gravity-mainnet-v1.6.1\`) via the Releases UI — the workflow only
attaches assets to a pre-existing release, so create the release with
notes first, then publish to push the tag. Release notes can simply
reference this PR.
- [ ] Verify the new release binary on a Staging Mainnet VFN (e.g.
\`vfn-1\`): the panic at \`network_config.rs:281\` should be gone,
\`journalctl -u gravity-vfn-1.service\` should advance past the
identity-load step.

## Why this slipped through v1.6.0

The first end-to-end use of the \`Release\` workflow in PR #710 was the
v1.6.0 tag itself, which happened after the Packer image switch to
Ubuntu 24.04. The dry-run did exercise build + upload-artifact, but did
not exercise running the binary against a node that uses \`source =
"gcp_secret"\` identities — that path only lives in the deployed Staging
Mainnet / mainnet config, and isn't covered by SDK unit/integration
tests. Consider adding a smoke job that runs \`gravity_node --help\` (or
a tiny config-load test) under \`--features gcp-secret-manager\` so
future regressions are caught at PR time, not at deploy time.

## References

- v1.6.0 panic backtrace captured live on \`vfn-1\` 2026-05-14 ~00:21
UTC
- Feature declaration: \`bin/gravity_node/Cargo.toml:13-21\`
(\`gcp-secret-manager = ["gaptos/gcp-secret-manager"]\`), explicitly
notes \`Off by default to keep the HTTP/TLS stack out of the default
build graph; enable when cluster.toml configures any node with
\`identity = { source = "gcp_secret", ... }\`.\`
- Original release workflow: PR #710 (commit \`e8594e7b\`)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: Richard1048576

.github/workflows/release.yml

@@ -64,11 +64,31 @@ jobs:
             exit 1
           fi
 
-      - name: Build gravity_node and gravity_cli
+      - name: Build gravity_node (with gcp-secret-manager)
+        # gravity_node's `gcp-secret-manager` cargo feature must be enabled or
+        # the binary panics on first startup when any node's identity is
+        # configured as `source = "gcp_secret"` (the production case for
+        # Staging Mainnet / future mainnet):
+        #
+        #   panicked at .../config/network_config.rs:281:25:
+        #   load identity blob for peer_id from GCP secret ...: GCP Secret
+        #   Manager support not compiled in. Rebuild aptos-config with
+        #   `--features gcp-secret-manager` ...
+        #
+        # The feature is declared on bin/gravity_node/Cargo.toml (not on the
+        # workspace), so we must scope cargo with `-p gravity_node` to make
+        # `--features` resolve. gravity_cli is built in a separate step
+        # below because it does not declare the same feature.
         shell: bash
         run: |
           set -euo pipefail
-          cargo build --profile quick-release --bin gravity_node --bin gravity_cli
+          cargo build --profile quick-release -p gravity_node --bin gravity_node --features gcp-secret-manager
+
+      - name: Build gravity_cli
+        shell: bash
+        run: |
+          set -euo pipefail
+          cargo build --profile quick-release -p gravity_cli --bin gravity_cli
 
       - name: Stage release assets and compute sha256
         id: stage