ansible: add site.yml, and rename the monitoring group off the host's name

site.yml is a TABLE OF CONTENTS, not a second source of truth. It is 25
import_playbook: lines and comments - no `hosts:`, no `roles:`. Which hosts get
what stays on the `hosts:` line inside each playbook, exactly where it already
was; nothing moved. Every role is already wrapped in a thin playbook carrying
its own `hosts:` line, so there is no roles-vs-playbooks split to reconcile:
from here everything is a playbook.

What it buys:

  What runs on a host?  ansible-playbook site.yml --limit <host> --list-hosts
  Who gets thing Y?     the `hosts:` line in Y's own playbook
  What is a host?       ansible-inventory --graph

Note --list-hosts, not --list-tasks: the latter prints every play regardless of
--limit, so it will happily show you the bitcoin play under memos-box.

Nine playbooks are deliberately excluded and the file names every one with a
reason, so it accounts for all of them: the three infra/4xx monitoring plays
(still assert on the removed Uptime Kuma credentials and fail immediately),
910_docker (says `hosts: managed`, but Docker is on 5 of 11 managed hosts and
those 5 are exactly the ones that need it - running it installs Docker on the
Bitcoin node and the hypervisor), two nodito one-shots, the Kuma notification
setup, and two deliberate manual actions.

Writing it surfaced an inventory collision. There is a HOST named `monitoring`
in [vps] AND a group [monitoring], so Ansible warned and resolved `hosts:
monitoring` to the host:

  [WARNING]: Found both group and host with same name: monitoring

The group is renamed to [observability]; the host keeps its name. [caddy:children]
and the two ntfy playbooks follow. Behaviour is unchanged - `hosts: monitoring`
already resolved to the host - but the ambiguity is gone and the warning with it.

Verified: inventory graph is warning-free, site.yml passes --syntax-check, and
per-host play counts are identical before and after the rename.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

ansible/inventory.ini

@@ -2,6 +2,7 @@
 vipy ansible_host=167.172.107.33 ansible_user=counterweight ansible_port=22 ansible_ssh_private_key_file=~/.ssh/counterganzua
 watchtower ansible_host=164.92.239.72 ansible_user=counterweight ansible_port=22 ansible_ssh_private_key_file=~/.ssh/counterganzua
 spacey ansible_host=64.227.112.128 ansible_user=counterweight ansible_port=22 ansible_ssh_private_key_file=~/.ssh/counterganzua
+monitoring ansible_host=64.226.70.190 ansible_user=counterweight ansible_port=22 ansible_ssh_private_key_file=~/.ssh/counterganzua
 
 [nodito_host]
 nodito ansible_host=192.168.1.139 ansible_user=counterweight ansible_port=22 ansible_ssh_private_key_file=~/.ssh/counterganzua
@@ -15,7 +16,6 @@ memos_box_local ansible_host=memos-box lan_ip=192.168.1.145 ansible_user=counter
 forgejo_runner_local ansible_host=forgejo-runner-box lan_ip=192.168.1.132 ansible_user=counterweight ansible_port=22 ansible_ssh_private_key_file=~/.ssh/counterganzua
 arbret_staging_local ansible_host=arbret-staging-box lan_ip=192.168.1.147 ansible_user=counterweight ansible_port=22 ansible_ssh_private_key_file=~/.ssh/counterganzua
 small_backups_local ansible_host=small-backups-box lan_ip=192.168.1.131 ansible_user=counterweight ansible_port=22 ansible_ssh_private_key_file=~/.ssh/counterganzua
-nonkeiwaisi_local ansible_host=nonkeiwaisi-box lan_ip=192.168.1.151 ansible_user=counterweight ansible_port=22 ansible_ssh_private_key_file=~/.ssh/counterganzua
 
 # Local connection to laptop: this assumes you're running ansible commands from your personal laptop
 [lapy]
@@ -27,8 +27,12 @@ prd-arbret ansible_host=167.99.242.62 ansible_user=counterweight ansible_port=22
 [edge]
 vipy
 
-[monitoring]
+# The group is `observability`, NOT `monitoring` — there is a HOST named
-watchtower
+# `monitoring` on line 5, and a group with the same name makes `hosts: monitoring`
+# ambiguous. Ansible resolved it to the host and warned:
+#   [WARNING]: Found both group and host with same name: monitoring
+[observability]
+monitoring
 
 [vpn_control]
 spacey
@@ -64,7 +68,7 @@ nodito_vms
 # Hosts that run Caddy and therefore have /etc/caddy/sites-enabled.
 [caddy:children]
 edge
-monitoring
+observability
 vpn_control
 
 [backup_store]

ansible/services/ntfy/deploy_ntfy_playbook.yml

@@ -1,5 +1,5 @@
 - name: Deploy ntfy and configure Caddy reverse proxy
-  hosts: monitoring
+  hosts: observability
   become: yes
   vars_files:
     - ./ntfy_vars.yml

ansible/services/ntfy/setup_ntfy_uptime_kuma_notification.yml

@@ -12,7 +12,7 @@
 # What was being monitored: archive/uptime_kuma/MONITORS.md
 # ═════════════════════════════════════════════════════════════════════════════
 - name: Setup ntfy as Uptime Kuma Notification Channel
-  hosts: monitoring
+  hosts: observability
   become: no
   vars_files:
     - ./ntfy_vars.yml

ansible/site.yml

@@ -0,0 +1,82 @@
+---
+# Everything, in the order it has to happen.
+#
+# This file is a TABLE OF CONTENTS, not a second source of truth. It says what
+# runs and in what order. It does NOT say which hosts get what — that stays on
+# the `hosts:` line inside each playbook, exactly where it is today. Nothing
+# moves; this file only makes the set readable in one place.
+#
+#   What runs on a host?   ansible-playbook site.yml --limit <host> --list-hosts
+#   Who gets thing Y?      the `hosts:` line in Y's own playbook
+#   What is a host?        ansible-inventory --graph
+#
+# Run a slice with --limit, or run one playbook directly as before. Nothing here
+# changes how any individual playbook behaves.
+
+# ── Baseline: every managed machine ─────────────────────────────────────────
+- import_playbook: infra/01_user_and_access_setup_playbook.yml
+- import_playbook: infra/02_firewall_and_fail2ban_playbook.yml
+- import_playbook: infra/900_install_rsync.yml
+- import_playbook: infra/920_join_headscale_mesh.yml
+# 910_docker says `hosts: managed`, but only 5 of 11 managed hosts have or need
+# Docker. Left out until it has a [docker] group — see the note in PLAN_7.
+
+# ── The hypervisor ──────────────────────────────────────────────────────────
+- import_playbook: infra/nodito/31_proxmox_community_repos_playbook.yml
+- import_playbook: infra/nodito/32_zfs_pool_setup_playbook.yml
+- import_playbook: infra/nodito/34_nut_ups_setup_playbook.yml
+
+# ── Reverse proxy, before anything that registers a vhost ───────────────────
+- import_playbook: services/caddy_playbook.yml
+
+# ── Services ────────────────────────────────────────────────────────────────
+- import_playbook: services/bitcoin-knots/deploy_bitcoin_knots_playbook.yml
+- import_playbook: services/fulcrum/deploy_fulcrum_playbook.yml
+- import_playbook: services/datum-gateway/deploy_datum_gateway_playbook.yml
+- import_playbook: services/mempool/deploy_mempool_playbook.yml
+- import_playbook: services/memos/deploy_memos_playbook.yml
+- import_playbook: services/forgejo-runner/deploy_forgejo_runner_playbook.yml
+- import_playbook: services/phoenixd/deploy_phoenixd_playbook.yml
+- import_playbook: services/headscale/deploy_headscale_playbook.yml
+- import_playbook: services/vaultwarden/deploy_vaultwarden_playbook.yml
+- import_playbook: services/forgejo/deploy_forgejo_playbook.yml
+- import_playbook: services/lnbits/deploy_lnbits_playbook.yml
+- import_playbook: services/ntfy/deploy_ntfy_playbook.yml
+- import_playbook: services/ntfy-emergency-app/deploy_ntfy_emergency_app_playbook.yml
+- import_playbook: services/personal-blog/deploy_personal_blog_playbook.yml
+
+# ── Backups: each source dumps itself, the box pulls ────────────────────────
+- import_playbook: services/headscale/setup_backup_headscale.yml
+- import_playbook: services/vaultwarden/setup_backup_vaultwarden.yml
+- import_playbook: services/forgejo/setup_backup_forgejo.yml
+- import_playbook: services/lnbits/setup_backup_lnbits.yml
+- import_playbook: services/memos/setup_backup_memos.yml
+- import_playbook: playbooks/backups.yml
+
+# Deliberately not here. Every playbook in the repo is either imported above or
+# listed below, so this file accounts for all of them:
+#
+#   infra/410_disk_usage_alerts.yml     assert on the Uptime Kuma credentials that
+#   infra/420_system_healthcheck.yml    were removed from the vault, so they fail
+#   infra/430_cpu_temp_alerts.yml       before doing anything. What they deploy IS
+#                                       running on the boxes - same state the two
+#                                       nodito playbooks were in before 0f03c50.
+#                                       Add them once they are de-Kuma'd.
+#
+#   infra/910_docker_playbook.yml       says `hosts: managed`, but Docker is on 5
+#                                       of 11 managed hosts and those 5 are exactly
+#                                       the ones that need it. Running it would
+#                                       install Docker on the Bitcoin node and the
+#                                       hypervisor. Needs a [docker] group first.
+#
+#   infra/nodito/30_proxmox_bootstrap   one-shot: bare-metal bootstrap, run once
+#   infra/nodito/33_..._cloud_template  one-shot: builds the VM template
+#
+#   services/ntfy/setup_ntfy_uptime_    creates a notification channel INSIDE
+#     kuma_notification.yml             Uptime Kuma. Kuma-specific tooling, not
+#                                       a deployment.
+#
+#   services/vaultwarden/disable_       deliberate manual actions, not convergence
+#     vaultwarden_sign_ups_playbook.yml
+#   services/personal-blog/setup_
+#     deploy_alias_lapy.yml