fix(module): coverage over nothing is not coverage

[rldyourmnd]

gds module coverage reported success having compared no module against any gate.

The defect

An estate whose repositories are not declared as git-submodule-consumer relationships gets:

{"result": "succeeded", "exit_class": "success", "data": {"modules": []}}

Success over an empty set. That is indistinguishable from every module being covered, and the estates most likely to hit it are exactly the ones asking whether their gates are watched at all.

setup-systems found it: they ran it against eight repositories expecting a verdict on fourteen required contexts each, and got green over nothing. This command exists to catch a gate drifting away from its declaration — the same class of defect arriving inside the tool meant to find it.

There was already a guard for the narrower case: --module <name> that matches nothing returns GDS_MODULE_COVERAGE_SELECTION_UNKNOWN. The unselected empty case had none.

The change

Empty scope now emits GDS_MODULE_COVERAGE_SCOPE_NOT_PROVEN, carrying declared_relationships so the reason is legible rather than inferred:

{"result": "not-proven", "exit_code": 3,
 "findings": [{"code": "GDS_MODULE_COVERAGE_SCOPE_NOT_PROVEN",
               "evidence": {"declared_relationships": 0, "repository_id": "repo_…"}}]}

Not-proven rather than validation. An estate with no declared modules is not invalid — a standalone repository legitimately has none. But nothing about its gates was proven either, and that is what exit 3 says. The classifier keys NOT_PROVEN in the code name to ExitNotProven, so the name carries the classification.

Testing

There were no tests for CoverModules at all, which is part of why this shipped.

The new test runs the real command against this repository, which declares no relationships, and asserts the specific finding code rather than a non-zero exit. That distinction turned out to matter: with XDG_CONFIG_HOME redirected to a temp dir — the pattern the neighbouring tests use — the command fails earlier at GDS_POLICY_ESTATE_NOT_PROVEN and never reaches this path. A test asserting only exitCode != 0 would have passed while covering nothing, which is the defect this PR fixes, in the test for it.

Verified by mutation: replacing the guard condition with false makes the test fail; restoring it passes.

Projections

core/app is one of the source paths the bundle lock digests, so the fix changed the source tree identity. Regenerated through gds generate repository plan/apply; --check reports no findings and the full suite is clean.

[rldyourmnd]

The test I shipped first was green on my machine and red in CI, for exactly the reason this PR exists.

core/cli had it running the real command against this repository. That reached the guard locally only because a registered estate happened to be configured here; CI has none, so gds module coverage failed earlier at GDS_POLICY_ESTATE_NOT_PROVEN and the test never touched the path it claimed to cover. A test asserting exitCode != 0 would have been green over the wrong refusal in both places — I only saw it because the assertion names the finding code.

So the defect reproduced itself inside its own test, one layer up. Moved to core/app against appTestRepositoryRoot, which builds an external estate in a temp directory and exports GDS_ESTATE_ROOT, so the test carries its own preconditions instead of borrowing the developer's.

Verified in both directions again on the new location: mutating the guard to false makes it fail, and it passes with HOME, XDG_CONFIG_HOME, XDG_STATE_HOME and GDS_ESTATE_ROOT all cleared — the CI shape.