[Epsirom]

Change

Part of RSI Mode (#118). Replaces the per-edge limit added in #124 with an optional maxRuns on every node type. It lands before #127 (arbitrary cycles), which no longer needs to prefer limited edges when it picks closing edges, and before 0.6, so edge limits were never released.

People think "review at most 3 times", not "this edge fires n-1 times", and with arbitrary cycles it is hard to tell which edge closes a cycle or to bound overlapping cycles at a shared node with one edge's limit. A node limit has none of those problems.

Behavior

• maxRuns counts the executions of a node's lineage that start; skipped ones do not count. Unlimited when omitted or Infinity. maxRuns: 3 on a node in a cycle allows three rounds.
• When an edge reaching a settled head would rerun it past maxRuns, the clone is still created but stays pending with the new wait reason limit. Once its inputs are current, core emits limit_reached (limit: "maxRuns", the waiting executionId) and lists it in the new BraidSnapshot.limitedExecutionIds and graph_waiting.limitedExecutionIds, so a run with nothing else active waits and Pi/DSH wake the owner with the waiting reminder.
• Raising maxRuns with a normal update/upsertNodes edits the pending rerun in place and it starts.
• Releasing it with resume (or resume in an update) without raising ends the rerun: it is removed (execution_removed), the node keeps its last result, and nothing downstream reruns for it. In a cycle this mirrors the old "release without raising ends the loop": the decision chose the closing edge, so its exits stay inactive. If the same update raises maxRuns, the rerun starts instead.
• An owner's replacement of a started node is never blocked; the limit only caps automatic reruns (cycle rounds and downstream cascades).
• Under onLimit: "fail" the run fails with the new code RUN_LIMIT.

Removed

Edge.limit, the rule that a limit must sit on a cycle-closing edge, the edge_limit hold source, limit_reached.edge, and EDGE_LIMIT. Cycle validation is otherwise unchanged. removeEdges now accepts only from, to, and choice.

Pi and DSH

• Node schemas accept maxRuns; edge schemas drop limit. Tool guidance, onLimit text, and braid_update/braid_resume descriptions explain raising or releasing a waiting rerun.
• The waiting reminder lists a rerun at its limit as a WaitingItem of kind limited (source maxRuns) and says how to raise or release it. formatEdgeLimit and edgeLimit on completion notices are removed. Pi's OutstandingJob and the single-shot drain warning include limited reruns.
• Status text shows maxRuns= on nodes, the limit wait reason, and reruns at their limit. The Pi live view restores the previous head when a rerun is released. The DSH panel drops edge limits and shows a node's maxRuns.
• /braid:review bounds its rounds with maxRuns: 3 on its writer node instead of an edge limit and still fails at the cap.

Docs

Execution control (cycles, wait reasons, graph_waiting, Limits), README graph schema and options, resource limits, the 0.6 migration in docs/compatibility.md (maxIterations n becomes maxRuns n on a node in the cycle), ROADMAP scope table, and both adapter READMEs.

Compatibility

Not breaking against released versions: edge limits were never released. Callers of 0.5 still migrate maxIterations as described in the 0.6 guide, now to maxRuns.

Validation

npm run verify passes (core 303, Pi 194, DSH 68, package smoke). Edge-limit tests are replaced by maxRuns tests: raising in place and releasing to end a cycle, RUN_LIMIT, downstream reruns versus the owner's replacement, skipped runs not counting, releasing while an input still reruns, removing a node and releasing its rerun in one update, and validation. Pi and DSH tests cover the waiting reminder, schemas, /braid:review, and the live-view restore.

• Relevant tests and type checks pass.
• User-facing docs are updated where needed.
• The title reads as a release-note line and the category label is correct.
• Breaking changes, if any, include migration guidance in the docs.