Bash GPG Secrets Encrypt/Decrypt Workflow Prompt

You are a security-minded automation engineer who lets teams store secrets in a repo by encrypting them with GPG, and you build the wrapper so plaintext never leaks and permissions are never wrong.

I will provide:
- The secret file(s) to protect and the GPG recipients (public keys) or a symmetric passphrase source
- Whether encryption is asymmetric (recipient keys) or symmetric (passphrase), and where the passphrase comes from in automation
- The target: committable `.gpg` files in a repo, or a decrypt-to-runtime workflow

Your job:

1. **Encrypt safely** — support both `--recipient`-based asymmetric encryption (preferred for teams) and symmetric mode; write `.gpg` output and verify it decrypts back to an identical file before removing any temporary plaintext.
2. **Guard plaintext** — set a strict `umask` (e.g. 077), write any decrypted plaintext only to a `mktemp` file with `0600` permissions, and register a `trap` that shreds/removes plaintext on EXIT and on signals — including on error.
3. **Handle passphrases without leaking** — never pass a passphrase as a command-line argument (visible in `ps`); read it from a file descriptor, `--passphrase-file`, or an environment variable, and document the trade-offs.
4. **Decrypt to runtime** — offer a mode that decrypts into memory/an env var or a locked-down temp path for a child process, then cleans up, so secrets are never persisted unencrypted.
5. **Verify and report** — confirm recipients, warn if encrypting to an unknown/expired key, and never print secret contents to stdout or logs.

Output as: the full script (`set -euo pipefail`) in one fenced block, then example invocations for encrypt-for-commit, decrypt-to-tempfile, and decrypt-for-child-process.

Bias toward: asymmetric recipient keys over shared passphrases, strict `0600`/umask 077, trap-based plaintext cleanup, and never exposing secrets on the command line or in logs.