fix(gate-54): a correct nested relation was unrepresentable to the check (#231)

[rubenvdlinde]

Closes #231. Supersedes #241 (that branch fixed only the false-positive half and shipped no runnable def test_; it is closed in favour of this one).

Cause

property_ids was built by a single non-recursive loop over schema.properties.*, while _raw_walk() recursed into the entire document and flagged every x-relation-filter whose containing dict was not in that set.

So a relation nested in items.properties.* was reported as "placed off a property" unconditionally. That is not a judgement, it is arithmetic — _raw_walk finds the node, the collector can never contain it, the finding always fires.

The finding was unfixable in the app. larpingapp's character.requirementOverrides.items.properties.skill is byte-for-byte the same shape as character.skills twenty lines above, which the gate accepts; the only difference is nesting depth. The three ways to clear it — move the filter off the property, flatten the array-of-objects, delete the filter — are all wrong.

The same blind spot ran the other way for checks (b), (d) and (f): a nested relation missing its $ref, carrying a dangling $ref, or carrying an invalid filter token was never inspected at all. The gate was simultaneously false-positive on shape and false-negative on the thing that matters.

Fix

One recursive collector, _collect_properties(), replaces the flat loop and feeds all the checks. It descends items.properties.* (both dict and tuple-items forms) and properties.* for inline objects, guarded by an id() seen-set and a depth cap — a crashed gate reports nothing, which reads exactly like a pass.

Three invariants deliberately preserved, each pinned by a test:

• items is a subschema, not a property. A filter riding the items node is still a genuine rule-6 violation and is still reported.
• @object.<field> still resolves against the ROOT schema at every depth. @object is the object under edit, not the array element. larpingapp's nested @object.setting points at character.setting; resolving against the element would have manufactured a fresh false positive.
• Rule-10 (frozen lifecycle) stays top-level. A lifecycle field names a property of the schema, never an element of a nested array.

Acceptance — three proofs, all real runs

(a) True positive still caught. Never widen a checker until it catches nothing. Fixture with a filter on an x-* block and one inside items but not on a property — both still reported:

x-relation-filter at /components/schemas/character/properties/badFilterOnItems/items is placed off a property ...
x-relation-filter at /components/schemas/character/x-openregister-ui is placed off a property ...

(b) False positive gone. larpingapp@development, full-tree, all register files:

BEFORE (origin/main): 4 findings
AFTER  (this branch): 3 findings
removed: lib/Settings/larpingapp_register.json: x-relation-filter is placed off a property ...

The one removed line is the false positive. All three genuine findings survive.

(c) False negative closed. A nested relation with no $ref — silent on origin/main, reported now:

character.missingRefNested.items.skill — relation-shaped property (format:uuid + relation description) lacks canonical $ref (ADR-062 rule 7)

Finding count vs defect count

Gate-53 turned ~132 defects into "240 violations" because one missing _note emitted a triplet, so this helper was audited for the same shape. Exactly one overlap: a property with x-relation-filter and no $ref matched check (b) and check (c) — one defect, one fix, two messages. Check (c)'s duplicate is now suppressed when (b) already reported that property, so the ratio is 1:1. Check (d) stays per-token by design (three bad tokens are three defects).

Placement findings now name the node

They named only the FILE. A register emitting three of them gave the reader three identical lines for three different nodes — that ambiguity is exactly what made #231 hard to triage. They now carry a JSON pointer.

Fleet re-measure (19 apps' registers, read-only)

The placement false positive existed only on larpingapp. Closing the false negative surfaces 8 previously-silent nested missing-$ref findings: scholiq 4, decidesk / hermiq / openbuild / openconnector 1 each. Check (b) is property-level diff-scoped in CI, so these only surface on a PR that touches those lines — no repo goes red on landing.

Honest caveat: of those 8, at least two (hermiq CourseRecommendation.recommendations.items.courseId, openconnector source...credentialRef.credentialId) are cross-register FKs where a local $ref cannot resolve, so they are not fixable by adding one. That is a pre-existing weakness of check (b)'s prose heuristic which this change gives more reach; it is filed separately rather than patched under this issue with a prose carve-out.

Tests

New suite test_check_relation_dialect.py, auto-discovered by run-helper-suites.sh: 0 → 24 tests. Full suite on the rebased tree: 29 passed, 2 quarantined, 0 failed.

Every new test mutation-checked (each mutation applied, suite run, mutation reverted, suite re-run green):

mutation	tests that went red
disable the items recursion	10
collect items itself as a property	2 (both true-positive guards)
remove the (b)/(c) dedupe	1
remove the depth == 0 lifecycle guard	1
remove the depth cap	2
anti-widening control — collector accepts everything	4 (all 3 true-positive tests)
whole suite vs origin/main's helper	16 of 24

Touches only check_relation_dialect.py and its new test file.