feat(hierarchies): template {var:NAME} resolves in-transaction (M6)

Route/trigger template `{var:NAME}` placeholders now resolve against vars
applied in the SAME `pic apply` transaction, not committed-only state — so a
var and a template referencing it converge in one apply instead of two.

- config_resolver: add tx-scoped `fetch_var_candidates_tx`, sharing the SQL
  tail (`VAR_CANDIDATES_TAIL`) with the pool variant so they can't drift.
- apply_service: `expand_route_templates_tx`/`expand_trigger_templates_tx`
  read vars via the tx (vars are reconciled in Phase A / the app's own
  reconcile, both before Phase B expansion).
- templates journey: `route_template_var_resolves_in_same_apply` — would fail
  against the old committed-only read.
- doc §4.5: strike the `{var:NAME}` committed-only limitation.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/design/groups-and-project-tool.md

@@ -404,8 +404,9 @@ Two distinct constraints:
 > check (cron schedule, queue timeout, …) — so a `{var:…}`-injected reserved path, unclaimed strict
 > host, or malformed schedule/timeout can't slip in. **Scope:** expansion targets app NODES present in the tree apply
 > (the common `pic apply --dir` case), not yet every descendant in another repo — deleting a template
-> leaves expansions in out-of-apply descendants until they're re-applied (the apply warns);
-> `{var:NAME}` resolves against *committed* vars (a var set in the same apply lands next apply). A
+> leaves expansions in out-of-apply descendants until they're re-applied (the apply warns).
+> `{var:NAME}` resolves **in-transaction** (M6, 2026-06-28) — a var set in the *same* apply is visible to
+> the template immediately, so var + template converge in one apply. A
 > trigger template whose only change is a non-identity field (e.g. dispatch_mode) is a no-op on
 > re-apply, mirroring the existing trigger-identity limitation (recreate to change those).