charter template: a measured fact in an addendum must carry its own deletion trigger

Propagated from claude-bridge CLAUDE.md. Placed in the canonical block's boundary
paragraph, not in the orchestration body: that paragraph is already about the
addendum layer rather than about protocol, every project that mounts the bridge
inherits it, and it sits about 3800 characters before the primary's step list, so
it does not dilute the steps a lead reads while working.

The reasoning is the fleet01 lead's. Its kb addendum held a dated merge-refusal
section carrying an instruction to delete itself once it stopped reproducing. On
2026-09-08 UTC the operator granted merge rights, the lead re-ran the probe, got
409 where it had got 405, and deleted the section as instructed.

The lead's point, which is the one worth keeping: what made the banner work was
not emphasis. It was that the falsification condition was executable. The banner
carried the exact probe, the reason for the all-zeroes head_commit_id, and what
each response code meant, so the lead did not have to reconstruct the experiment
or decide what would count as refutation. A banner reading 'this may be out of
date, verify before relying on it' costs the same space and does nothing, because
deciding what would falsify a claim is the expensive step and a reader in the
middle of another task will not pay it. Hence four parts, not one: the date, the
command, what each outcome means, and the instruction to delete.

The last clause names why this machinery is worth its space at all. Most stale
notes are merely wrong. This one went stale in the dangerous direction: it would
have told a future lead it could not merge at the moment merging became its job,
silently and with confidence. A note that goes harmlessly stale does not need
this.

Sync check in the claude-bridge addendum reports 'in sync: True'.

7-Use-Cases.md

@@ -312,6 +312,14 @@ really does report the old mount name.
 > wiki ([Use Cases](https://git.ltms.dev/fleet/fleetd/wiki/7-Use-Cases) → *The portable
 > CLAUDE.md block*); improvements go to the template first, then out to each project. Anything
 > specific to *this* repo lives under §Project addendum below, never inline above it.
+>
+> **Anything you measure in an addendum is perishable.** Date it, give the command that
+> re-measures it and what each outcome means, and tell the reader to delete the section once
+> it stops reproducing. The four parts work together: deciding what would falsify a claim is
+> the expensive step, and a reader in the middle of another task will not pay it, so a bare
+> "verify before relying on this" costs the same space and does nothing. The case this is for
+> is a note that goes stale as a live restriction — it will tell a future session it cannot do
+> the thing at the moment doing it becomes the job.
 
 If no `fleet_*` MCP tools are mounted in this session, this section does not apply — skip it.