Formalize maintainer set and governance model

[demohan]

PR #96 introduces an RFC process whose acceptance rule depends on "maintainers": at least two must approve, none may request changes. For now we are treating the people listed in .github/CODEOWNERS as the maintainer set, which is pragmatic but informal:

• There is no public list of who counts as a maintainer.
• There is no documented process for adding or removing maintainers.
• The CODEOWNERS file is uniform across paths today, so it does not reflect actual ownership specialization.
• External contributors have no way to know who can vote on an RFC, who decides FCP, or what the path to becoming a maintainer looks like.

Proposed follow-up work

1. Add MAINTAINERS.md listing maintainers, their areas, and contact info.
2. Add GOVERNANCE.md covering: how decisions get made, how new maintainers are added, how maintainers can step down or be removed, and the relationship between maintainer status and CODEOWNERS entries.
3. Once MAINTAINERS.md exists, update rfcs/README.md to point at it as the source of truth for "maintainer," replacing the current "use CODEOWNERS as the maintainer set" stopgap.

Not urgent. The current rule works for a small AWS-internal set of maintainers, but it will not scale once external contributors start submitting RFCs or want a path to become maintainers themselves.

References

• rust-lang/rfcs has a model worth borrowing from.
• ASF projects (Cassandra) have a more formal voting structure that may be overkill at this stage.