fix(cli): architecture rules select nothing on Windows — every path helper returns backslashes

Start in cli/tests/architecture/helpers.ts, especially sourceFiles() and the other helpers that return relative() paths; inspect how the 15 architecture test consumers use those paths. Run the architecture project on Windows, then verify that forward-slash matching works and that the 100 tests either pass or report genuine violations rather than selecting no files.

Description

cli/tests/architecture/helpers.ts builds every path it hands to a rule with
relative(CLI_ROOT, full), which is platform-native. On Windows that yields
src\contexts\tools\..., while the rules themselves match on forward slashes —
startsWith("src/contexts/"), includes("/profiles/"), and similar.

Nothing throws. The rules simply select nothing, and 21 architecture tests fail on
Windows with messages that read like the repository drifted rather than like the
harness did: "the rule selects no file — its scope is stale", "no profile
directory found", "pattern matches nothing under src/".

The more serious half is not the noise, it is the silence on the other side: any
architecture rule a contributor adds is unverifiable on Windows, and a Windows
contributor cannot tell a real violation from a harness that selected zero files.

Affected file(s)

• cli/tests/architecture/helpers.ts — sourceFiles(), and every helper returning a
  relative() path
• 15 of the 25 files under cli/tests/architecture/, as consumers

Expected behaviour

The architecture project passes on Windows, or names a real violation when one exists.

Observed behaviour

On next at 126e88da, a pristine checkout, no local modification:

--project=architecture    21 failed | 79 passed (100)

The same commit is green in CI (cli CI: success), so this is platform-specific and
invisible to the pipeline.

Root cause, reproduced directly:

relative(CLI_ROOT, join(CLI_ROOT, "src", "contexts", "tools", "domain", "x.ts"))
// -> "src\contexts\tools\domain\x.ts"
//    startsWith("src/contexts/tools") === false
//    includes("/profiles/")           === false

normalize is imported in the file but is not applied at this point.

Additional context

Found while implementing #862, and it is the same defect class: a path or shell
assumption that holds on Linux and macOS, breaks on Windows, and reports nothing.
#862 is one hook that never runs; this is 21 rules that never select. Both are
invisible to a Linux-only CI, which is what #707 exists to close.

Deliberately not fixed inside the #862 branch: normalising the separators would make
21 rules run on Windows for the first time, and some may then surface genuine
findings. That is a discovery task with an unbounded cost, and how this harness should
treat Windows is a maintainer decision.

I agree to follow this project's Code of Conduct.