docs(friction): include_tasks tag-propagation + check-mode gotchas (M3)

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

docs/FRICTION.md

@@ -21,6 +21,20 @@ earning its keep.
 
 _(append new raw signals here; the next kaizen review consumes them)_
 
+- `[gotcha]` **A tag on `include_tasks` does NOT reach the included tasks — need
+  `apply: {tags:}`** (2026-06-14): M3's `base/tasks/main.yml` tagged the ssh/fail2ban
+  `include_tasks` with `hardening`, but `make deploy … TAGS=hardening` ran *nothing*
+  (`ok=3 changed=0`) — a tag on a dynamic include selects the include, not its contents.
+  Fix: `include_tasks: {file: x.yml, apply: {tags: [hardening]}}`. The same latent bug sat
+  in the firewall include (never hit — firewall was only ever run untagged). Also the
+  check-mode artifact: a `service`/handler for a not-yet-installed package fails in a
+  first-run `--check` → guard with `when: not ansible_check_mode`. Both caught only by the
+  **live `make check`/`deploy` on askari** — Molecule converges *untagged*, so it can't
+  catch tag-propagation. 3rd reinforcement (after M1 `item.values`, M2 TF
+  `required_providers`) that live execution catches what review + container tests miss.
+  → when a role uses tags to apply concern-subsets, `apply:` is mandatory on its includes;
+  consider an ansible-lint/CI check that `make deploy … TAGS=<concern>` actually changes things.
+
 - `[gotcha]` **Terraform child modules need their own `required_providers` for
   non-hashicorp providers** (2026-06-14): `terraform init` for the `offsite` env failed —
   the `hetzner_vm` module used `hcloud_*` resources with no `required_providers` block, so