fix(ci): drop a dependency list that flagged real edges

[LKSNDRTMLKV]

Closes #347 — and the issue is right that the claim is false, but wrong about where it lives, which matters for the fix.

The quote is not in CLAUDE.md

#347 attributes "dpp-types and dpp-common are standalone" to CLAUDE.md's Dependency direction section. It is not there. The only occurrences of "standalone" in CLAUDE.md describe services and ports — the resolver, the identity service, the in-memory job store. Its dependency diagram draws the platform stack above dpp-core with dpp-types as the anchor, which is correct as drawn.

The sentence's only home is .coderabbit.yaml, in the crates/**/*.rs path instructions. So this changes one file, not two.

Every clause of that list was wrong

Derived from the Cargo.toml files rather than from the prose:

the list said	actually declares
dpp-types standalone	dpp-domain, dpp-rules
dpp-dal: types + domain	+ dpp-common
dpp-vault: dal, types, common, domain	+ dpp-vc, dpp-crypto, dpp-digital-link, dpp-registry, dpp-calc, dpp-rules
dpp-integrator: types + common	+ dpp-domain, dpp-rules
dpp-node: vault, identity, integrator, common	+ dal, types, render, seal, plugin-host, resolver, and five core crates

dpp-seal, dpp-plugin-host, dpp-resolver and dpp-render were not in the list at all. The instruction ended "Flag any edge outside that list", so the reviewer was told to flag most of the workspace.

What it cost

On #356 this produced a 🟠 Major recommending that TrustServiceStatus be duplicated into dpp-types and converted at the dpp-seal boundary, to close a "public type leak". There was no leak: dpp-types has declared dpp-domain since it was written, and two things merged this morning return core types straight from its public API — SuccessorLookup::successor_of returns dpp_domain::passport::Passport, and TrustedListStore returns DppError. The finding was declined, but only after the argument was had.

The fix is to stop enumerating

Replacing the list with a corrected list would recreate the failure — and this file already names that anti-pattern, two paragraphs later, about version pins: "read the pin there and never from a copy restated in prose, which is how one document claimed 0.1.0 for fourteen releases." The graph has the same property: it has one home, in the Cargo.toml files, and any copy of it decays.

So the paragraph now says the edges are declared in Cargo.toml, says not to flag an edge for being absent from a list here, records what the old list got wrong so the next person does not restore it, and keeps the one invariant that is genuinely load-bearing:

dpp-common is shared infrastructure and carries no dependency on dpp-domain or any other core crate. A regulatory predicate, a domain type or a core import appearing there is a real finding.

That one is checked and true — dpp-common/Cargo.toml declares no dpp-* dependency at all — and it is the edge whose absence means something, which is exactly what a reviewer cannot read off a Cargo.toml at a glance.

YAML re-parsed after the edit; path_instructions still has its four entries.