feat: Wire the Bitwarden catalog element into a reusable bundle for scenario credential distribution

[romainkieffer]

Description

Umbrella: #69
Wave: WAVE_04 (since 2026-06-05)
Cross-repo: range42/range42#198, range42/range42-ansible_roles-debug-devkit#114, range42/range42-catalog#178

range42-catalog will provide a self-contained Vaultwarden catalog element
(container + generic mapping-driven credentials.bitwarden get/set role —
see the companion issue in that repo).

This repo (range42-playbooks) hosts the reusable bundles/ (currently
core, ping) that scenarios include, and the scenarios/ that consume
them. This issue is about the wiring, not the container/role
implementation: any scenario that needs standardised credential distribution
should be able to spin up the Vaultwarden catalog element and push/pull
credentials as needed, without hand-rolling the catalog element's mapping and
task includes itself.

Scope:

1. Spin-up — a bundle that deploys the Vaultwarden catalog element (the
   container) as part of a scenario that opts in, using the same mechanism
   scenarios already use to pull in catalog elements.
2. Sync wiring — a documented, reusable pattern for a scenario to declare
   its own bitwarden_sync_map and call the catalog element's
   credentials.bitwarden role at the right point in its own playbook
   (after service provisioning creates users/API keys).

This is opt-in: a scenario only spins up Vaultwarden and syncs credentials if
it explicitly declares it needs to.

Working branch

feature/bitwarden-sync-bundle

Files / locations

range42-playbooks/bundles/credentials-bitwarden/            - bundle: deploys Vaultwarden catalog element + wraps credentials.bitwarden get/set
range42-playbooks/bundles/credentials-bitwarden/README.md   - how to declare a sync map and spin up Vaultwarden from a scenario
range42-playbooks/scenarios/demo_lab/                       - example wiring in an existing scenario (proof of concept)

Note: paths above are workspace-level for now and may be adjusted later.
Depends on the Vaultwarden catalog element landing in `range42-catalog` first.

Requirements

• Bundle stays generic: it should accept a bitwarden_sync_map from whatever
  scenario includes it, not hardcode any scenario's credentials.
• Document, with a concrete example, how a scenario author spins up
  Vaultwarden and adds credential sync without needing to understand the
  underlying role's internals.
• Proof-of-concept wiring in at least one existing scenario (e.g. demo_lab
  or misp_lab once it exists) to validate the spin-up + get/set flow
  end-to-end.
• Keep behaviour opt-in: scenarios that don't declare a sync map must be
  completely unaffected (no Vaultwarden container, no new required vars).

Open questions (to resolve later)

• Which credentials get synced by default: is there a "standard" set
  every opted-in scenario should push (e.g. admin SSH key, first-boot
  password) versus fully scenario-specific opt-in?
• Bundle vs scenario-level role call: should this be a formal bundle/
  (like core), or is a documented pattern for calling the catalog role
  directly from a scenario's playbook enough?
• Timing: push after every playbook run, or only on first
  provisioning/rotation events?
• Shared vs per-scenario Vaultwarden instance: does the bundle spin up a
  new Vaultwarden container per scenario, or connect to one shared instance
  for the whole CODENAME? (depends on the lifecycle question in the
  range42-catalog issue)