test(proto): gate the rule that per-OS code lives in platform (R14)

[haiquang9994]

CLAUDE.md says no #[cfg(windows)] in core/daemon code and the tree obeys it, but
nothing checked. It does now, beside the layering test.

The suggested rule could not be written as stated. "Fail on an OS cfg outside a
#[cfg(test)] region" assumes #[cfg(test)] is one mod tests at the foot of a file.
Here it sits on an impl, on a single match arm, on a pub(crate) mod fake, on
individual functions — and seven files carry more than one. There is no region a line
scan can find, and brace-counting files that are full of braces inside string literals
fails open, which is the wrong direction for a gate.

So it takes deny.toml's shape instead: two files permitted by name with a written
reason, everything else refused, and a permitted file must hold exactly one
#[cfg(test)] with every OS cfg after it. That last clause is what keeps the permission
from widening — a file that grows a second #[cfg(test)] fails rather than silently
meaning nothing.

Watched failing three ways before it was trusted: an unpermitted file, a permitted file
with the attribute above its test module, and a permitted file with two #[cfg(test)].

cfg! is deliberately not caught. Forty-odd cfg!(windows) sit in production code
and they are a different thing: both arms compile, type-check and are reachable from a
test on every OS. #[cfg] deletes code from the build, so the other two platforms
compile a different program. standards/rust.md now says so, and points at
recipes/mysql.rs, which goes further and passes windows as a function argument.

CI: green. The first run had one unrelated red — test (windows-latest) failed in the
real-Caddy suite with .caddy.staging\Caddyfile: The system cannot find the file specified, which is the document::install staging race already written up in that
function's own doc, now reproduced a second time. It is not this change's (a test in
proto and two markdown files cannot reach that suite) and it is not fixed here.