Deep-dive audit: bring MuseHub org infrastructure to full CLI/functionality parity

Deep-dive audit: bring MuseHub org infrastructure to full CLI/functionality parity

Background

While onboarding aaronrene (see issue #58) and scoping issue #123 (wiring up the gabriel+aaronrene org specifically), found that org support is real but partial:

• Real backend routes exist (musehub/api/routes/api/orgs.py): create org, add/list/remove member with read/write/admin weight.
• Zero CLI support — muse hub org isn't a recognized subcommand at all. Every other MuseHub capability (repos, issues, proposals, labels, collaborators, releases, webhooks, attestations...) has a full muse hub <noun> <verb> CLI surface; orgs don't.
• Unclear whether repo ownership/permission-checking anywhere is actually org-aware (e.g. "this repo is owned by an org, and the requester is a member of that org" as a valid write-access path) — transfer_repo_ ownership's backend is built around a single owner_user_id string with a docstring that says "transfer to a new user," not obviously org-aware.
• Quorum enforcement (check_quorum(), QuorumEngine, IdentityPushValidator) is real and documented, but has not been exercised end-to-end against a real, live org — see issue #123's open question about whether self-approval is currently permitted, which is exactly the kind of edge case a full audit needs to resolve deliberately rather than discover by accident.

This ticket is the tracking placeholder for a proper deep-dive: walk the entire org/quorum feature end to end and bring it to the same completeness bar as every other MuseHub entity (full CRUD CLI, documented permission model, tested edge cases) — not a specific implementation plan yet.

Goal (to be fleshed out when picked up)

• muse hub org has full CLI parity with other entities: create, read, list, update (e.g. quorum threshold), delete; member add/remove/list/ update-permission.
• A clear, tested answer for every "is this org-aware?" question this ticket surfaces — repo ownership, collaborator permission resolution, quorum voting mechanics (including the self-approval question from #123), proposal-merge governance enforcement.
• Any real gaps found get fixed or explicitly deferred with a documented reason — not silently left ambiguous.

Relationship to issue #123

#123 is the narrower, concrete task of standing up one specific org (gabriel + aaronrene) using whatever primitives already exist, as fast as reasonably possible. This ticket is the broader, slower audit of whether those primitives are actually complete and correct as a general capability. #123 should not block on this ticket — do #123 first to unblock aaronrene, then use whatever's learned there as real input when this ticket gets properly scoped.

Out of Scope (for now — this is a placeholder, not a plan)

Everything is provisional until this is picked up and properly scoped — including phases, test IDs, and acceptance criteria, none of which are written yet on purpose.