design: evaluate OpenTofu for declarative management of the mson group

Context

bart applies desired project/group config without persistent state, so it can converge settings but can't detect drift, reconcile deletions, or show a plan/diff before applying. Recent manual fixes (per-repo renovate/* protected-branch rules, container repository protection rules) are exactly the drift-prone, declarative work state-backed tooling is built for.

Proposal

Evaluate the gitlab OpenTofu provider for state-backed management of the mson group and projects: projects, members, protected branches, container/registry protection rules, CI/CD variables, service accounts, with plan/diff and drift correction.

bart is retained, not replaced. Candidate roles:

• Audit / compliance reporting (overlaps #35): report drift and policy violations even where tofu owns apply.
• A simpler custom API surface for actions the provider doesn't expose, or where a bespoke limited interface beats HCL.

To evaluate

• Provider coverage gaps: newer features (container protection rules) may lack resources, leaving raw API calls (as bart does today).
• State backend (GitLab's managed Terraform state is on Free) and the bootstrap/privileged token (same chicken-and-egg bart has).
• Division of responsibility: tofu (apply/state/drift) vs bart (audit / custom surface).
• Whether bart becomes a tofu wrapper or stays a sibling, likely ADR-worthy.
• Registry path conventions (release vs dev image/cache repos) and cleanup policies as an example of per-repo policy worth templating across member repos (see mr-reporter#54 (closed)).

Relates to #35.

Generated with Claude Code