Support additional ownership sources beyond CODEOWNERS and catalog-info.yaml

[raiderrobert]

Problem

Organizations don't just have two ownership sources — they have 3, 4, 5+. The reconciliation engine should be extensible so users can check alignment across whatever sources they use.

Known ownership sources

File-in-repo (same fetch pattern as catalog-info.yaml)

• Datadog Service Catalog (service.datadog.yaml / entity.datadog.yaml) — YAML with team: field. Same in-repo pattern makes this straightforward to add.
• OpsLevel (opslevel.yml) — service catalog, optional file-based config.
• package.json / pyproject.toml / Cargo.toml — author/maintainer fields. Informal but sometimes used as ownership signal.

API-only (requires external service credentials)

• PagerDuty — service-to-team mapping, drives incident routing.
• GitHub repo team permissions — which teams have write/admin access. Different from CODEOWNERS (who reviews vs who can push). If a team is in CODEOWNERS but doesn't have write access, that's broken.
• OpsGenie — alert routing ownership, similar to PagerDuty.
• ServiceNow CMDB — service ownership in ITSM.

Design consideration

The reconciliation engine should use a trait-based approach for ownership sources, making it straightforward to add new sources without changing core logic. Something like:

trait OwnershipSource {
    fn name(&self) -> &str;
    fn fetch(&self, repo: &str) -> Option<String>;  // returns team/owner identifier
}

File-in-repo sources share a fetch pattern (GitHub contents API + parse). API-only sources each need their own client and auth.