fix(seeds): relax documents cardinality, re-point the mcp ingress

Rehearsing the deploy against a full copy of prod surfaced 40+ cardinality
violations that would have failed the seed. Since api/scheduler/notifier all
depend on `seed: service_completed_successfully`, and this change alters the
seed files (so the content hash changes and a full re-ingest runs for the
first time in months), that failure would have stopped those services from
starting at all.

None of them are new. The foreign-key bug in checkdefaults was aborting the
ingest earlier, during entity ingest, so ValidateCardinality at the end never
got the chance to run. Fixing the first failure revealed the next.

- `documents` was declared many-to-one, meaning a document may document at
  most one entity. Nomos has been writing docs that cover several (a
  fleet-wide apt audit documents every host it touched) for months, which is
  reasonable — the ontology was the strict one. Now many-to-many.
- The mcp ingress still routed to service:homelab-mcp, which prod marks
  deprecated: the Python MCP server on apps/105 was stopped at the Go cutover.
  Nomos re-pointed it at service:oikos on 2026-07-12 and was right; the seed
  was stale, and re-asserting the old edge alongside the new one is what made
  it a violation.

Remaining after this: one genuine drift, `hosts target=lxc:caddy (2 edges)`,
which needs a prod data fix rather than a code change — see the follow-up.

Co-Authored-By: Claude <noreply@anthropic.com>

seeds/inventory.yaml

@@ -446,7 +446,12 @@ relationships:
   - {source: "ingress:trmnl.hubris.network", target: "service:trmnl", type: routes-to}
   - {source: "ingress:zimaos.hubris.network", target: "service:zimaos", type: routes-to}
   - {source: "ingress:teddy.hubris.network", target: "service:teddycloud", type: routes-to}
-  - {source: "ingress:mcp.hubris.network", target: "service:homelab-mcp", type: routes-to}
+  # Re-pointed from service:homelab-mcp, which is deprecated — the Python MCP
+  # server on apps/105 was stopped at the Go cutover and mcp.hubris.network now
+  # fronts the Go api. Nomos recorded this correctly on 2026-07-12; the seed
+  # was the stale one, and re-asserting the old edge alongside it is what made
+  # ingress:mcp a cardinality violation.
+  - {source: "ingress:mcp.hubris.network", target: "service:oikos", type: routes-to}
   - {source: "ingress:secrets.hubris.network", target: "service:secrets-issuance", type: routes-to}
   - {source: "ingress:house.hubris.network", target: "service:house", type: routes-to}
   - {source: "ingress:books.hubris.network", target: "service:grimmory", type: routes-to}

seeds/ontology.yaml

@@ -970,7 +970,12 @@ relationship_types:
     inverse: documented-by
     source: document
     target: entity
-    cardinality: many-to-one
+    # many-to-many, not many-to-one: a single investigation routinely covers
+    # several entities (a fleet-wide apt audit documents every host it
+    # touched), and Nomos has been writing such edges for months. The stricter
+    # declaration made ~40 of them cardinality violations, which only surfaced
+    # once the seed could complete far enough to run ValidateCardinality.
+    cardinality: many-to-many
     description: Document describes an entity.
   involves:
     inverse: involved-in