Rewrite GOVERNANCE.md: subprojects, maintainer committees, contributor ladder

[gbartolini]

Draft the updated GOVERNANCE.md reflecting the federated subproject model.

Split from the original scope (see epic #65): this ticket now covers
the subproject/technical-authority split and contributor ladder only. The
Steering Committee's target composition (seats, org cap, staggered terms,
elections) moves to #70, and org-balanced voting stays with #68, so the
two pieces can be reviewed and merged independently — subprojects first,
then Steering's composition.

Acceptance criteria

• Define the four subprojects and their repo scope:
  • Core: cloudnative-pg, api, machinery, barman-cloud
  • Supply Chain: charts, artifacts, community-operators, postgres-containers, postgres-extensions-containers, pgbouncer-containers, postgis-containers, postgres-trunk-containers, daggerverse, ciclops, chaos-testing, github-test
  • Community, Docs & Ecosystem: docs, cloudnative-pg.github.io, cnpg-playground, grafana-dashboards, webtest
  • Extensibility: cnpg-i, cnpg-i-machinery, plugin-barman-cloud, klio, cnpg-i-hello-world, postgres-keycloak-oauth-validator
• Document that governance, .project, .github, cnpg-infra, and cnpg-template sit outside any subproject, administered directly by Steering
• Each subproject has its own self-selecting maintainer committee holding technical authority over its components (subprojects/*.md, MAINTAINERS.md)
• Introduce the Component Owner / Subproject Maintainer contributor ladder (CONTRIBUTOR_LADDER.md)
• Enumerate what the Steering Committee owns vs. what stays with subproject maintainer committees
• For this step, the Steering Committee is the existing group of Maintainers (MAINTAINERS.md), deciding under the existing per-person voting rules (lazy consensus, simple majority, ⅔ for governance changes) — its target composition (seats, org cap, elections) is explicitly out of scope here, see Form the Steering Committee and hold first meeting #70
• Name and define the Infrastructure Team (delegated by Steering; the existing admins GitHub team)
• PR reviewed and merged in cloudnative-pg/governance

Context

This is the single largest deliverable in the restructuring: most other
tickets in this epic depend on the definitions here. Split from the
original single-PR scope specifically so subprojects/ladder can land and
be reviewed on their own footing, without also asking reviewers (and,
later, the TOC) to evaluate the Steering Committee's composition and
org-balanced voting in the same pass.

[gbartolini]

The README already lists all our repositories, so I'd rather keep the repository-to-subproject classification there than in GOVERNANCE.md (any change there would otherwise require a Steering Committee vote). GOVERNANCE.md should only define the subprojects themselves.

Here's what I'm currently leaning towards:

• Core Projects: just the operator itself, for now.
• Supply Chain, grouping: Container Images, Libraries & Automation, Testing & Automation, plus a new "Distribution" category covering the three main ways we ship the software (artifacts for YAML manifests, charts for Helm charts, community-operators for OLM bundles).
• Community, Docs & Ecosystem, renamed from the original proposal's "Community, Docs & Monitoring." Grafana dashboards are all we have today, but the intent is closer work with other projects, especially in the CNCF space, not just observability.
• Extensibility, grouping: Interface & Plugins (CNPG-I), and PostgreSQL Extensions & Tooling (renamed from "Modules & Extensions" - see below).

A few notes on the reasoning:

• Supply Chain is also meant to cover the work we're doing with OpenSSF in preparation for the EU Cyber Resilience Act. That work is the foundation for a future conformance-program application for CNPG — possibly as its own subproject at that point.

• Extensibility: CNPG-I and Postgres extensions/modules are the two ways we extend the stack's two main components: CloudNativePG and PostgreSQL, respectively. I'd like to keep the door open for Postgres tooling that works beyond Kubernetes and isn't limited to compiled extensions (application libraries, or even backup and recovery tooling), which is why that category is "PostgreSQL Extensions & Tooling" rather than just "Modules & Extensions."