feat: add Bitbucket support to code_repository and service_definition modules

[pablovilas]

Summary

Adds Bitbucket as a first-class git provider to the nullplatform/code_repository and nullplatform/service_definition modules. This is the tofu-modules slice of the cross-repo Bitbucket support program (Plan 09 / periphery), bringing the modules to parity with GitHub / GitLab / Azure DevOps and aligning them with the organization-setup contract that already accepts bitbucket.

Contract honored: provider value bitbucket; provider-spec type slug bitbucket-configuration with attributes setup.workspace, setup.project_key, setup.email, setup.api_token (sensitive), setup.installation_url (default https://bitbucket.org), setup.flavor (cloud), access.collaborators; canonical repo URL https://bitbucket.org/{workspace}/{slug}.

nullplatform/code_repository

• variables.tf: validation widened from ["github","gitlab"] to ["github","gitlab","azure","bitbucket"]. The previous list silently rejected Azure, which the module already fully implemented (resource, is_azure local, azure_* vars) — fixed alongside Bitbucket.
• locals.tf: added is_bitbucket.
• main.tf: added a bitbucket-configuration nullplatform_provider_config resource, mapping setup.{workspace,project_key,email,api_token,installation_url,flavor} and access.collaborators from new variables, mirroring the gitlab/github/azure blocks (namespace stripped from NRN via replace()).
• New inputs: bitbucket_workspace, bitbucket_project_key, bitbucket_email, bitbucket_api_token (sensitive), bitbucket_installation_url (default https://bitbucket.org), bitbucket_flavor (default cloud), bitbucket_collaborators. Required fields validated when git_provider == "bitbucket".
• Added a bitbucket_provider_config plan test.

nullplatform/service_definition

• variables.tf: validation widened from ["github","gitlab","local"] to ["github","gitlab","bitbucket","local"]. Azure is not added here because data.tf only wires github/gitlab spec fetching — the module genuinely does not support Azure as a spec source, so it stays out.
• locals.tf: added bitbucket_repo_url (https://bitbucket.org/{org}/{repo}, matching the canonical URL contract) and bitbucket_raw_prefix; made the URL/header selection an explicit per-provider chain rather than a positional github ? … : (gitlab) fallback.
• data.tf: added an explicit Bitbucket branch to all three spec-fetch data sources.

Bitbucket authentication (Basic vs Bearer)

The Bitbucket auth header adapts to the credential type:

• Atlassian API token (the program's standard bot-user credential) — authenticates only via HTTP Basic email:api_token and returns 401 on a Bearer header. Set the new optional bitbucket_email input and the module sends Authorization: Basic base64(email:api_token).
• Bitbucket workspace/repository access token — leave bitbucket_email null and the token is sent as Authorization: Bearer <token>.

Both modes are documented on the bitbucket_email variable and in the README.

Validation

• tofu validate — passes in both modules.
• tofu test (code_repository) — 4/4 pass, including the new Bitbucket run.
• tofu fmt -check -recursive — clean; terraform-docs README input tables regenerated.

Repo sweep (gap 3)

Checked every contains([...]) validation and provider conditional in the repo. Only code_repository and service_definition gated git providers; both fixed. nullplatform/account's repository_provider has no validation (already permissive — accepts bitbucket). All other contains([...]) checks are for unrelated concerns (cloud_provider, k8s_provider, dns_provider, api_key type, etc.) and were left untouched.

Note: the <!-- BEGIN_AI_METADATA --> blocks are machine-generated (integrity-hashed) and refreshed by external automation, not terraform-docs; they are intentionally left for that automation to regenerate.

🤖 Generated with Claude Code