fix(tools): forward set_skill_env and set_effective_trust through CompositeExecutor

[bug-ops]

Summary

• CompositeExecutor now forwards set_skill_env and set_effective_trust to both inner executors.
• Without this override, the base ToolExecutor impls (no-ops) were inherited, silently swallowing both calls at the very first CompositeExecutor boundary — which in production is always the outermost layer (src/agent_setup.rs:534-541).
• Concrete impact:
  • Skill secret env injection broken: x-requires-secrets declarations parsed correctly and available_custom_secrets populated, but ShellExecutor::skill_env stayed None, so GITHUB_TOKEN (and any other declared secret) was never present in the bash subprocess env. Verified live in TUI: skill github active at confidence 0.98, env | grep GITHUB → NO_TOKEN.
  • Trust-gate enforcement bypassed: TrustGateExecutor::effective_trust stayed at the initial Trusted regardless of the active skill's trust level. QUARANTINE_DENIED tools (bash, write, web_scrape, etc.) were reachable while a quarantined skill was active.
• Added two regression tests in composite::tests::state_forwarding using a nested CompositeExecutor tree and spy executors at every leaf, asserting both setters land on all leaves.

Closes #3869.

Test plan

• cargo +nightly fmt --check
• cargo clippy --workspace --all-targets -- -D warnings
• cargo nextest run -p zeph-tools --lib --bins → 1174 passed (incl. 2 new regressions)
• cargo nextest run --workspace --lib --bins → 9322 passed
• Manual: rerun the original live-test scenario from CI-783 (TUI + bash $ env | grep GITHUB) and confirm GITHUB_TOKEN now present when github skill is active.

Notes

• The fix is a forwarding override on CompositeExecutor, not a behavior change in any leaf executor. The defaults in the ToolExecutor trait remain no-ops — only intermediate composition no longer drops the call.
• No public API surface changes. Trait method signatures are unchanged.