Extend the repo-registry data model to support subnet-funded pool association

[JSONbored]

Problem: #6099 defines the entity model for subnet-funded pools (subnet, repo, pool as distinct related entities) but the current registration data model (RegistryRepoConfig in src/types.ts, populated via normalizeRegistryPayload/registrySnapshots) is entirely repo-keyed with no way to associate a repo with a funding pool or subnet identity. Nothing in loopover's own storage can currently represent "this registered repo has a subnet-funded pool" at all.

Area: Platform / gittensor economics — registry data model

Proposal: Add an optional pool association to the existing repo-registration data model — a nullable poolId (matching #6098's SettlementBackend interface's own poolId field) plus a subnet identifier, attached to a RegistryRepoConfig/repositories row without changing anything about how an unfunded (organic) repo registration works. Additive only: a repo with no pool association behaves byte-identical to today.

Deliverables:

• Schema/type extension: poolId and subnet identifier fields, nullable, on the repo-registration data path.
• A read accessor that returns a repo's pool association (or null) — the thing Persist rental-ledger consumption entries against the settlement-backend interface #6314's PayoutEligibleEvent construction and any future pool-state reporting UI (per Design spec: subnet-level onboarding & registration flow (extends #4789's individual-customer pattern) #6099) would read from.

Acceptance criteria:

• An organic (non-subnet-funded) repo's registration round-trips byte-identical to today — no poolId/subnet fields set, no behavior change.
• A repo with a pool association can be read back with its poolId and subnet identifier intact.

Resources:

• Design spec: subnet-level onboarding & registration flow (extends #4789's individual-customer pattern) #6099 (entity model this implements) and Design spec: settlement-backend interface (gittensor-owned or self-built, pluggable either way) #6098 (SettlementBackend's poolId shape this must match)
• src/types.ts's RegistryRepoConfig, src/registry/normalize.ts

Boundaries:

• No settlement mechanics, no pricing/allocation numbers, no UI.
• Does not change organic (non-pool) repo registration behavior in any way.

---

Part of #6101.

[linear-code]

JSO-4411