Guardrail deny layer (.claude/settings.json) is not enforced on non-Claude engines

## Gap

The merge/close/force-push deny layer (`gh pr merge`, `gh pr close`, `gh issue close`, `gh repo delete`, `git push --force`/`-f`) is currently implemented as `.claude/settings.json` permissions, which only Claude Code's engine mechanically enforces. `README.md`'s "Caveats for non-Claude engines" section already flags this, but there's no fix yet — on `codex`, `gemini`, `opencode`, or `custom` engines, the playbook (`STEWARD.md`) still *instructs* the same guardrails, but nothing blocks a bad action if the model ignores them.

This matters more now that the steward is regularly run under `opencode` (currently `deepseek/deepseek-v4-pro`) rather than Claude.

## Proposed fix

Rather than hand-translating the same allow/deny list into each engine's own permission config (uneven support — Codex's sandbox doesn't do per-subcommand denies at all, opencode/Gemini have their own differing schemas, `custom` has none), enforce it one layer down: a thin wrapper script for `gh` and `git`, placed ahead of the real binaries on `STEWARD_PATH` (built in `install.sh:63-68`), that passes everything through except the denied subcommands/flags, which it refuses with a clear stderr message.

Every engine ultimately shells out to the same `gh`/`git` binaries, so this gives identical, mechanical enforcement regardless of `STEWARD_ENGINE` — no per-engine config to keep in sync, and `install.sh` already has the single choke point to prepend the wrapper dir.

Tradeoff to keep in mind: a refusal surfaces as a shell error the model has to notice and react to mid-turn, rather than the tool call being intercepted before it runs (as Claude Code's permission layer does). It also only covers `gh`/`git` shellouts — a future engine hitting GitHub's API directly instead of the CLI wouldn't be caught.

## Not doing yet

No code changes yet — just recording the gap and the intended direction before implementing.