docs: draft federated subproject governance model

[gbartolini]

• Split governance into two documents: GOVERNANCE.md (collective bodies and their authority) and CONTRIBUTOR_LADDER.md (individual progression), so each can be amended at its own threshold (⅔ org-balanced for the former, simple majority for the latter).
• Establish a federated model: a Steering Committee (5-7 seats, max 2 per organisation) sits above four Subproject Maintainer Committees (Core Projects, Supply Chain, Community, Docs & Ecosystem, Extensibility), each holding technical authority over its own repositories and selecting one representative to Steering.
• Split voting into organization-level decisions (org-balanced, one vote per organisation: Steering Committee elections, GOVERNANCE.md changes, CONTRIBUTOR_LADDER.md changes, adding/removing subprojects) and subproject-level decisions (per-person, lazy consensus falling back to a plain vote).
• Add a Community Representative election process: nominations open in a public Discussion in the governance repository, seats filled by ranked-choice voting (Condorcet or instant-runoff, e.g. via CIVS), and a vacancy rule that promotes the next-highest-ranked candidate from the original election before calling a special one.
• Add organizational cap enforcement for the 2-per-organisation Steering seat limit, covering election results, subproject committee selections, and affiliation drift from an acquisition or a job change. The cap binds from the Steering Committee's very first appointment rather than only after initial terms expire, so the restructuring cannot itself reintroduce, even temporarily, the single-organisation majority it exists to end.
• Add a documented path for proposing a new repository to join an existing subproject, and for archiving one that goes inactive, both decided by that subproject's own maintainer committee.
• Collapse the Reviewer rung into Component Owner. Folder-scoped CODEOWNERS recognition (e.g. a docs/ or testing/ owner within a larger repository) becomes an operational tag a repository's own Component Owners can assign to any Contributor for review-routing, carrying no vote, no additional GitHub permission, and no CNPG Organization Member status. The ladder is now Community Participant, Contributor, Component Owner, Subproject Maintainer, with Steering Committee membership deliberately kept off the ladder as a representative role rather than a rung climbed to.
• Redefine "component" as strictly a GitHub repository, dropping the earlier allowance for a functionally independent subdirectory to count as its own component.
• Rename "Organization Member" to "CNPG Organization Member" throughout, to avoid confusion with the org-balanced-voting sense of "organization" (the employer an individual works for).
• Restructure MAINTAINERS.md into per-subproject tables (Last Name, First Name, Handle, Organization, Component(s)) in place of bullet lists, and add an empty Steering Committee table, ready for Last Name, First Name, Handle, Organization, Seat, Email, Term Start, and Term End once seats are actually filled.
• Add three previously undocumented maintainers found by cross-referencing CODEOWNERS data against the committee rosters: Itay Grudev to Supply Chain (owns charts), Armando Ruocco to Community, Docs & Ecosystem (owns webtest), and Niccolò Fei to Extensibility (owns plugin-barman-cloud).
• Rescope CONTRIBUTORS.md to the Contributor tier specifically, removing nine names that had already progressed to Subproject Maintainer and are now recorded in MAINTAINERS.md instead, alongside a Component(s)-aware roster there.
• Replace COMPONENT-OWNERS.md with the subprojects/ folder, one file per subproject listing real CODEOWNERS-derived repository ownership, plus a root CODEOWNERS file scoping each subprojects/*.md file to its own subproject's maintainer committee.
• Update README.md's links to point at the new document set.
• Open items not resolved in this change, flagged inline for follow-up: the Steering Committee's term-stagger schedule, inactivity thresholds for any tier, the Security Response Team and Infrastructure Team rosters, and whether Component Owner status should count toward CNCF's own foundation-level maintainer list and mailing list.

Closes #67
Refs #69

Assisted-by: Claude