docs(contract): add CATALOG_REPO_CONTRACT.md

[JLCode-tech]

Summary

Canonical reference doc for every bnk-forge-catalog-* repository — so future Azure / GCP / on-prem catalog repos, and any third-party contributors, follow the same shape as bnk-forge-catalog-aws-eks.

What's covered

• Naming conventions — bnk-forge-catalog-<target> for JLCode-tech-owned repos; external catalogs may use their own naming.
• Per-release branching cadence — one branch per BNK release (release/2.2, release/2.3, …); main tracks the most recent.
• Required top-level files — README, .gitignore, VENDORED.* and vendor-refresh tooling when applicable.
• README requirements — what every catalog repo's root README must include (modules table, blueprints table, branch model, credential template compatibility, BNK registration outputs, Forge import instructions).
• Directory layout with example tree.
• Module naming — <target>-<step> (e.g. eks-cluster-register).
• Module structure — required files, bnkforge.pack.json schema with forbidden values (no source: project_secret), module.json retention during transition.
• Blueprint structure — full forge-blueprint.json schema with bnk_version, platform_defaults, prerequisites, inputs, modules array.
• Cross-module wiring — Forge auto-wires by name match across depends_on; blueprint manifests only reference blueprint-level inputs via ${var}.
• Two valid credential patterns: (A) IBM-style cloud-coupled — creds to every module; (B) cloud-agnostic — only cluster-register gets creds, downstream uses Forge-injected forge_kubeconfig_content. Both are valid; a single blueprint can mix.
• Vendoring rules — pristine copies, deterministic rewrites, auto-refresh discipline, no hand-editing vendored files.
• Validation steps every PR should run before opening.
• Adding a new catalog repo — step-by-step.
• Open questions — defer-until-needed items called out explicitly.

Why now

bnk-forge-catalog-aws-eks PR #2 shipped the first complete vendor-and-chain slice. Codifying the contract now means Azure / GCP / on-prem don't have to reverse-engineer the pattern.

Test plan

• Merge to release/2.2
• Reference this doc from each new per-cloud catalog repo's README
• Update Forge developer docs to link to this doc as the authoritative source

Notes

• The contract document itself is not yet versioned. If a backwards-incompatible change becomes necessary, we'll add a top-level version field at that point.
• The doc lives at the repo root so it's discoverable from the repo home page. If we accumulate enough catalog-related docs, consider moving it under docs/.