feat(scan): add REQUIRE_SIGNED to forbid unsigned rules

[joeymussalli]

trustabl verifies rules against an embedded trust keyring by default and exits 2 rather than running unverified rules. It also keeps an unsigned git path, and --require-signed exists specifically to forbid the fallback to it in CI.

This plugin never offered that flag, while exposing two inputs that reach the unsigned path: RULES_REPO, exported unconditionally as TRUSTABL_RULES_REPO, and RULES_REF, which pins a git ref. Neither is wrong to use -- pinning a ref is a reasonable way to get reproducible scans -- but a security gate should be able to state the requirement rather than inherit whatever the default resolves to, and until now there was no way to say "never accept unsigned rules".

docs/EVALUATION.md already tells readers that rules are "fetched at scan time from a signed channel". That is true of the tool's default, but nothing in this plugin held it to that, so the guarantee the documentation offers was not one a user could enforce.

• REQUIRE_SIGNED=true adds --require-signed. Default false, so behaviour is unchanged for everyone who does not opt in.
• Matched case-insensitively. Silently ignoring REQUIRE_SIGNED=TRUE would be a fail-open on the single input whose purpose is to tighten the gate. STRICT has the same case-sensitivity and is deliberately left alone: changing it is a behaviour change for existing users and belongs in its own PR.
• Documented in a new "Rule integrity" section of the README, alongside what RULES_REPO and RULES_REF each mean for integrity, because those two are the reason the flag is worth having.

Verified: the flag reaches BASE_ARGS for true/TRUE/True and is absent for unset/false/yes; STRICT's existing true/false/TRUE behaviour is byte-identical before and after. bash -n passes. No scan was run -- this changes which arguments are constructed, not what the scanner does with them.