chore(CODEOWNERS): remove blanket-ownership file

[bearomorphism]

Description

Remove the repo-wide CODEOWNERS rule that assigned every path to all three maintainers.

* @woile @Lee-W @noirbizarre

Because GitHub treats CODEOWNERS owners as required (or at least auto-requested) reviewers, this single line caused every PR -- regardless of scope -- to request review from all three maintainers. That's review-request spam and doesn't reflect who actually maintains each area today.

Why now / data behind the change

I ran git log per subtree over the last two years to see who actually touches each area. Highlights (commit counts; Yu-Ting Hsiung and Tim Hsiung are the same person -- @bearomorphism -- confirmed by commit email):

Area	Top contributors (commits, 2y)
commitizen/ core	@bearomorphism 144, @Lee-W 16, @noirbizarre 5, @woile 3
commitizen/commands/	@bearomorphism 74, @Lee-W 8
commitizen/providers/	@bearomorphism 11, @Lee-W 4, others 3
commitizen/changelog_formats/	@bearomorphism 8, @Lee-W 3, grahamhar 3
commitizen/cz/, commitizen/config/	@bearomorphism dominates
docs/	@bearomorphism 65, @Lee-W 13, @woile 8, @noirbizarre 6
tests/	@bearomorphism 84, @Lee-W 11, @noirbizarre 8
.github/, CI, pyproject.toml	@bearomorphism 29, @Lee-W 26, @noirbizarre 20

Two observations:

1. Ownership in practice is heavily concentrated, not evenly shared across the three listed maintainers.
2. A blanket * rule with three names is the worst-case configuration: it maximises notification spam while providing no routing signal about who is best placed to review.

What I considered instead

A per-area CODEOWNERS (e.g. commitizen/providers/ @X, .github/ @Y, docs/ @Z) was the obvious alternative. I'm not proposing that here for two reasons:

• Picking primary owners per area is a social decision the maintainers should make explicitly, not something to ship in a drive-by PR.
• The current data shows one person touching almost every area, so any "per-area" split would either still ping the same person everywhere or under-route reviews. Better to start from a clean slate.

Once maintainers agree on per-area primary owners, a more granular CODEOWNERS can be reintroduced in a follow-up.

Checklist

• I have read the contributing guidelines

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: GitHub Copilot CLI following the guidelines

Code Changes

• Add test cases to all the changes you introduce -- N/A, only a .github/ governance file is removed; no code paths are affected.
• Run uv run poe all locally to ensure this change passes linter check and tests -- N/A for a single-file deletion in .github/; pre-commit hooks ran clean on the commit.
• Manually test the changes:
  • Verify the feature/bug fix works as expected in real-world scenarios -- verified the file is removed via git show --stat.
  • Test edge cases and error conditions -- no runtime behaviour changes.
  • Ensure backward compatibility is maintained -- no public API touched.
  • Document any manual testing steps performed -- see above.
• Update the documentation for the changes -- no docs reference CODEOWNERS.

Documentation Changes

N/A.

Expected Behavior

After merge, new PRs will no longer auto-request review from @woile, @Lee-W, and @noirbizarre purely on the basis of the CODEOWNERS rule. Maintainers can still self-assign or be requested by the PR author as appropriate.

Steps to Test This Pull Request

1. Confirm .github/CODEOWNERS is gone on this branch.
2. (Post-merge) Open a trivial PR against master and confirm no automatic reviewer request is added by GitHub's CODEOWNERS handling.

Suggested complement: auto-request Copilot code review

To replace the always-on review request without losing a default first-pass reviewer, consider enabling GitHub's built-in auto Copilot code review on this repo. A maintainer with admin access can do it via:

Settings -> Rules -> Rulesets -> New branch ruleset -> target master (and any release branches) -> tick "Automatically request Copilot code review".

Useful sub-options:

• Review new pushes -- re-runs Copilot's review after each push, not just once.
• Review draft pull requests -- catches issues before a human is pulled in.

Reference: https://docs.github.com/en/copilot/how-tos/use-copilot-agents/request-a-code-review/configure-automatic-review.

Notes:

• Requires the commitizen-tools org to be on a Copilot plan that covers code review (Business / Enterprise), or PR authors to have Copilot Pro/Pro+. If neither applies, this option simply won't appear in the ruleset UI.
• A few file types are skipped by design (lockfiles, logs, SVG). See https://docs.github.com/en/copilot/reference/review-excluded-files.
• This is purely a repo setting -- no file change needed in this PR.

The pairing -- drop the blanket CODEOWNERS rule, add the Copilot ruleset -- gives every PR an always-on first review without three human maintainers being requested by default.

Additional Context

No related issue. Happy to follow up with a per-area CODEOWNERS once @woile / @Lee-W / @noirbizarre agree on who should be the default reviewer for which subtree.