docs(security): say what the scanners cover and what guards the price

[TMHSDigital]

Secret scanning and push protection are on now. They recognise credential
formats. The closest thing to a disclosure this project has actually had was
not a credential: it was a vendor's price, quoted from their documentation into
a shipped config file, under an agreement that makes pricing information
confidential and expressly overrides the usual public-knowledge exclusion.

No scanner recognises a price. 0.042 is a float. Push protection would have
passed it through without a murmur, and did, until it was caught by reading.

That observation existed only in a chat log. This writes it down where it will
be read.

Changes

• SECURITY.md gains a section separating what the automated controls cover
  (credential formats) from what they do not (contractual confidentiality), and
  names the actual control: the --pricing design keeps tariffs in
  operator-supplied config, and a test asserts no shipped entry for that vendor
  carries a numeric figure.
• CONTRIBUTING.md gains one line under the adapter-config section, because
  that is the page someone reads before adding a vendor.
• docs/PLAN.md records the CodeQL decision with an exit condition.

The test was verified, not assumed

test_no_shipped_entry_states_a_figure_for_the_confidential_vendor was proven
to fail in both the ways that matter, by injecting a figure and watching it go
red:

1. A populated price field. Injecting input_usd_per_million=0.042 gives
   AssertionError: jev-1.13.0 / assert 0.042 is None.
2. A price quoted in prose, with the fields left as None. Injecting
   "$0.042 per Mtok input" into JEV_SOURCE trips the digit check on the
   source string.

Both were reverted and the suite is green. A guard that only looks like it
works is worse than no guard, so it seemed worth proving before writing a
document that points people at it.

CodeQL

Kept for its actions coverage rather than its Python coverage. Workflow
script injection is a real class of bug and ci.yml is where it would hide.
The Python queries are expected to be low yield here: a CLI with no attacker in
its threat model. The first full scan produced one alert, a false positive on a
test assertion that makes no security decision, dismissed with that reasoning.
PLAN.md records the threshold for turning it off: a second false positive on
ordinary work.

Docs only. No behaviour change.