docs(spec): clarify invariant phase boundaries and ACMS thread-safety model [AUTO-ARCH-23]

- Update invariant reconciliation to reflect enforcement at every phase boundary
  (before Strategize, Execute, Apply) not just Strategize (fixes #9899)
- Add thread-safety documentation for ACMS context tiers (threading.RLock)
  for read/write/evict operations (fixes #9859)
- Split Invariant glossary entry into shorter, clearer sentences for readability
- Add Plan Lifecycle section documentation of invariant reconciliation at each
  phase boundary (before Strategize, Execute, and Apply)

Addresses reviewer feedback from PR #10759

docs/specification.md

@@ -89,7 +89,7 @@ The following standards are integrated into the architecture:
     :   A persisted choice point in a plan's decision tree, created during Strategize or Execute. Records the question, chosen option, alternatives, confidence score, rationale, context snapshot, and downstream dependencies. Types: `prompt_definition`, `invariant_enforced`, `strategy_choice`, `subplan_spawn`, `subplan_parallel_spawn`, among others. Supports targeted correction with selective subtree recomputation.
 
     Invariant
-    :   A natural-language constraint on plan execution scoped to global, project, action, or plan level. The runtime precedence chain is four-tier: ==plan > action > project > global==. Exception: global invariants marked `non_overridable` always win regardless of scope. Reconciled by the Invariant Reconciliation Actor at the start of Strategize; recorded as `invariant_enforced` decisions that propagate to child plans.
+    :   A natural-language constraint on plan execution scoped to global, project, action, or plan level. The runtime precedence chain is four-tier: ==plan > action > project > global==. Exception: global invariants marked `non_overridable` always win regardless of scope. Reconciliation is performed by the Invariant Reconciliation Actor at each phase boundary — before Strategize, before Execute, and before Apply. This multi-phase enforcement catches invariants added or modified between phases. Each reconciliation run records `invariant_enforced` decisions that propagate to child plans.
 
     Automation Profile
     :   A named set of confidence thresholds (each `0.0`–`1.0`) gating which plan operations proceed automatically versus requiring human approval. `0.0` = always automatic; `1.0` = always manual. Eight built-in profiles (`manual` through `full-auto`). Custom profiles namespaced as `[[server:]namespace/]name`. Each profile composes a **Safety Profile** that controls hard safety constraints (sandbox, checkpoint, unsafe-tool gating, skill restrictions, cost/retry limits).
@@ -18410,6 +18410,8 @@ In this spec:
 
 The normal phase progression is forward, but both Execute and Apply may revert to Strategize when the current strategy's constraints are too restrictive (see *Phase Reversion* below).
 
+**Invariant reconciliation** is enforced at every phase boundary — before Strategize, before Execute, and before Apply. The Invariant Reconciliation Actor runs at each boundary to catch invariants that were added or modified since the previous phase. Each reconciliation produces `invariant_enforced` decisions in the plan's decision tree, which constrain downstream decisions and propagate to child plans.
+
 #### Phase Transition Verbs (CLI / UX Contract)
 
  Verbs that trigger phase transitions. CleverAgents should standardize these verbs as the **public API** (CLI, TUI, web):
@@ -44965,6 +44967,8 @@ This temporal chain is what enables the `temporal-archaeology` strategy to find
 | **Warm** | Recent decision contexts, plan context snapshots | `context.tiers.warm.retention-hours` (default: 24h) | Scoped query via plan hierarchy | Current + recently-expired nodes |
 | **Cold** | Archived decision contexts, historical UKO snapshots | `context.tiers.cold.retention-days` (default: 90d) | Full historical query | All temporal versions |
 
+**Thread Safety**: All tier mutations are protected by a reentrant lock (`threading.RLock`). Concurrent reads and writes are serialized at the tier level. The reentrant lock allows the same thread to acquire the lock multiple times (e.g., during recursive operations). Concurrency contract: `read()`, `write()`, and `evict()` each acquire the lock, perform the operation, and release the lock.
+
 #### Scoped Views and Plan Subgraph Projection
 
 ##### Resource Scope Resolution