docs(mdcode): split section 2's example, correct section 3's claims about affects

[libei]

Continues the sequential read-through of the merged actions guide. Two
sections, and the second one needed factual correction rather than
rewriting.

Section 2's spec and its worked example come apart

"A policy whose rules end differently" and "Two calls through that
policy" read as spec and as example at once, with no signal which was
which. The first opened on a five-rule business policy and then stopped
twice to state general rules about guards; the second walked a table of
outcomes that turned on one of those rules. A reader looking up how
guards compose had to read a credit example to find out, and a reader
following the example had to hold general machinery.

Three rules lived only inside the example, so anyone who skipped it never
learned them. The strictest-outcome precedence moves to "Naming a
constraint as a guard", which owns everything true of either constraint
kind. The warning an all-judged action loads with moves to "Rules no
query settles", beside the judged body it is about. What is left is an
example, so it becomes one: an unnumbered H2, "A credit policy, worked
through", skippable by its title the way "Carrying the write as DML" is.

The all-judged warning is also marked as current behavior rather than a
settled rule. warnAllGuardsJudged's own reason for warning instead of
erroring is that an all-judged action may be exactly what the author
meant, so the check fires on correct models; a reader who takes the
sentence as a rule will contort a model to avoid it. Whether a warning is
the right response is still open.

Section 3 was wrong about what affects drives

A read of the code behind affects refuted the section's two strongest
claims. "That key generation is the only thing affects drives" and "No
component computes an impact from it, routes on it, or checks it against
what your executor does" are both false on the same verb — affects
routes:

• resolve_profiles.ts:466-475 drops an action from a profile-resolved
  model when affects names a concept the profile cannot bind, so on
  that push the action is never published at all.
• kc_actions.ts:134-142 warns when a named concept has no entry in the
  push.

The status note now leads with the claim that survives — nothing compares
affects to what the executor does — and names the two places kcmd does
route on it.

Four more corrections in the same section:

• Key generation is a sql feature, which the section never said
  while opening on an mcp executor. planFromExecutor refuses any
  other kind (run_action.ts:937-938).
• The composite and non-String key check reads entities only.
  unusableGeneratedKey opens find(...); if (!entity) return null, so
  a relationship passes it, and an entity whose key names a field the
  model does not declare defaults to String and passes too. It runs at
  the call rather than at the push, which the section implied the other
  way round.
• Transfer gets a String key. The guide teaches key generation by
  creating a Transfer, and the example model keyed transferId as an
  Integer — exactly what the paragraph below it says kcmd refuses,
  which made the section's own example unrunnable. This is the first of
  the three fenced-block defects recorded on docs(mdcode): second pass on the actions guide — state it once, state it plainly #428, fixed here because it
  is this section's example.
• ir.ts claimed the generated key is "recorded as touched so the
  constraint probes cover the new row". Nothing records it, no such
  mechanism exists, and guards settle before the transaction opens, so no
  probe could observe a row that does not exist yet.

Section 3's lookup material gathers

concept, operation and fields were spread across two H3s and a
trailing paragraph with a modify aside between two of them. "What an
entry may say" now holds all three, and gains three rules the section
omitted: two entries on one concept with the same operation are a hard
load error, one bare entry beside one with an operation warns, and a
plain foreign-key edge has no fields of its own so naming one is always
an error — the guide's own TransferDebits is such an edge.

Two passages elsewhere depended on what section 3 got wrong

Section 4's "These checks are static, so they run on every push whatever
the destination" is not true of the concept and field checks.
validate.ts:219-221 builds the concept index only when fields are
unpruned, so a push resolving through a binding profile falls back to the
loader's warning, and only a catalog-only push or kcmd action run
treats those two as hard errors. Fields beside a delete read only the
entry, so that one does fail everywhere.

Section 7 stated "affects declares the blast radius rather than
limiting it" as if for the first time, four sections after affects was
taught. It now points back rather than re-deriving.

Key generation reconnects to the entry that causes it

"A created row gets its key from kcmd" arrived with nothing tying it to
the section around it. The heading's subject was a created row rather
than affects; the causal link was the paragraph's last sentence, after
the UUID, the binding name and the rationale; and the paragraph three
above it told the reader affects is checked "never against the
executor" and has "no way to confirm the write stays inside what you
named" — the status note's claim, stated twice, priming the reader to
expect nothing to happen.

The heading now names the cause in the vocabulary the slot rules just
taught — "Declaring a create turns on key generation" — the paragraph
opens on the link and moves its rationale below the example, the earlier
paragraph keeps only what the reader needs before the slot rules, and the
status note counts key generation as the first of the three things that
read affects.

Verification

Two fenced lines changed, both the Transfer key type, and the other 468
are byte-identical to main as a multiset. Prose stays inside 80
characters, no sentence either commit adds runs past 40 words, no
internal link broke, and the five inbound anchors from reference.md,
model_spec.md and the agent demo README resolve. Every changed line in
ir.ts is inside a doc comment.

The section 2 rename retires the anchor
#a-policy-whose-rules-end-differently, propagated to all three
references: two internal links and one from model_spec.md. Nothing
outside this repository links to it.

Two fenced-block defects from #428 remain for their own change: Figure 3
shows one UPDATE for a two-statement action and omits --arg target, and
a profile example is labelled commerce.profiles/operational.yaml inside
a model named payments.