Add repoOrigin (BYOR/APR) field to RegistryRepoConfig, mirroring poolAssociation's pattern

[JSONbored]

Context

RegistryRepoConfig (src/types.ts:452-467) already has a precedent for exactly this kind of addition: poolAssociation?: RepoPoolAssociation | null (#6320), added specifically so "an organic (non-pool) repo carries no pool fields and round-trips byte-identical to today." This issue does the same thing for repo origin: BYOR (customer's own pre-existing repo) vs. APR (loopover-provisioned) — currently unrepresented anywhere in this type.

Requirements

Add a new optional field to RegistryRepoConfig, mirroring poolAssociation's exact null-safety convention (absent/null = today's behavior, unchanged):

export type RepoOrigin =
  | { kind: "byor" }
  | { kind: "apr"; hostingOrg: string };

// on RegistryRepoConfig:
/** Repo provisioning origin (#7589). null/absent = existing byte-identical behavior — do not assume "byor" by
 *  default; absent means "not yet known/pre-dates this field", not "confirmed BYOR". */
repoOrigin?: RepoOrigin | null;

Do not add any repo-creation, GitHub API, or provisioning logic in this issue — this is a type-and-plumbing-only change, matching exactly what #6320 did for poolAssociation: add the field, thread it through wherever RegistryRepoConfig objects are constructed/parsed (the same places #6320 touched for poolAssociation — check that PR's diff for the exact call sites), and cover it with tests. No behavior changes for any repo where this field is absent.

Deliverables

• RepoOrigin type and RegistryRepoConfig.repoOrigin field added per the exact shape above.
• Every construction/parse site for RegistryRepoConfig updated to accept (and default to null/absent) this field, mirroring how poolAssociation is threaded through.
• Tests confirming a repo with no repoOrigin round-trips identically to today (byte-for-byte, same assertion style Extend the repo-registry data model to support subnet-funded pool association #6320 used for poolAssociation).

Test Coverage Requirements

src/types.ts and its consuming call sites are under src/** — standard 99%+ Codecov patch target applies, including both branches of any new conditional (present vs. absent repoOrigin).

Expected Outcome

The registry can represent whether a repo was customer-provided or loopover-provisioned, with zero behavior change for every repo that predates this field.

Links & Resources

• src/types.ts:440-467 (RepoPoolAssociation/RegistryRepoConfig — the pattern this mirrors)
• The PR that shipped Extend the repo-registry data model to support subnet-funded pool association #6320 (find via git log --oneline --grep=6320 or the issue's linked PR) — use its exact call-site list as the checklist for this issue's call sites
• Epic: dual-path repo provisioning — BYOR + APR #7589, Design spec: APR repo creation under the submitting customer's own GitHub account (twice-corrected) #7590 (BYOR+APR epic and hosting decision — the reason this is needed)

[linear-code]

JSO-5397