fix(docker): forward tool action signing secret in Compose (#15202)

## Thinking Path

> - Paperclip can run through Docker Compose.
> - Approval-gated tools need an independent signing secret.
> - The guide sets that secret before starting Compose.
> - Neither Compose file passes it into the container.
> - This pull request forwards the operator's configured secret.
> - Documented setup can issue signed tool-action approvals.

## Linked Issues or Issue Description

Fixes: #15064

## What Changed

- Forward PAPERCLIP_TOOL_ACTION_SIGNING_SECRET in both shipped Compose
environments.
- Document persistent deployment secrets and reuse on restart.
- Explain that it is independent from the session secret.
- Keep an empty default so deployments without approval-gated tools
retain their existing startup behavior.

## Verification

- Docker Compose config before the fix drops a supplied synthetic secret
in both files.
- After the fix, both preserve the supplied value.
- Both also resolve successfully when the optional signing secret is
absent.
- Used --env-file /dev/null and synthetic values. No containers were
started.
- `node --test scripts/docker-compose-secrets.test.mjs`: 2 passed.
- The Docker context CI lane runs this integration test.
- git diff --check passes.

## Risks

The value is visible to the container as intended. Operators must
protect it as a secret. This does not change admission rules or require
a new startup value for existing deployments.

## Model Used

OpenAI Codex, based on GPT-6, assisted with source review,
implementation and local test execution. The exact deployment model ID
and context-window size are not exposed in this session.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change and contains no internal
Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass (targeted local checks and
full remote CI pass)
- [x] I have added or updated tests where applicable (Hermes regression
/ real Compose interpolation checks)
- [x] I have updated relevant documentation to reflect my changes
(Hermes has no configuration changes; Compose documentation is updated)
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

.github/workflows/pr-trusted.yml

@@ -572,6 +572,14 @@ jobs:
       - name: Set up Docker Buildx
         uses: docker/setup-buildx-action@37fe631027851001ddb9b187196cc803df7f5f0e # v4
 
+      - name: Set up Docker Compose
+        uses: docker/setup-compose-action@54042514f505b273907334ae2b9cdbb9a0213c1a # v2
+        with:
+          version: v5.5.1
+
+      - name: Verify Compose signing secret forwarding
+        run: node --test scripts/docker-compose-secrets.test.mjs
+
       # Same .dockerignore semantics as the real image builds: a
       # context-slimming change that strips a committed build input must
       # fail here, on the pull request, instead of failing every