design: settle the four remaining UNDECIDED cases

[jayteemoney]

Closes #32. Second of Track A (#34). Nothing in behaviour.md is marked UNDECIDED any more — 34 scenarios, up from 31.

The interesting one is case 2, because the issue's premise was wrong

behaviour.md described cancel-after-end as probably harmless: "functionally a no-op cancel (refund = 0, since nothing is unstreamed) would be harmless if allowed."

That holds only when every milestone is resolved. With a milestone still unmet, the tranche has streamed in full but is entirely held, and the unapproved-milestone rule returns the whole thing to the sender:

at now >= end, milestone never approved
  streamed_total = 30,000,000,000   held = 12,000,000,000   withdrawn = 18,000,000,000
  claimable      = 0
  cancel() -> refund to sender = 12,000,000,000     <-- not zero

So it's a real transfer, and the decision matters more than the entry suggested. Permitted, because it is the only in-protocol way to resolve a milestone nobody ever approved — rejecting it would strand the tranche permanently, which is threat-model T3 arriving by a second route. The lifecycle diagram gains the Completed --> Canceled arrow it was missing.

Knock-on: this is a strong argument for creating grant streams cancelable, now stated in concepts.md.

The other three

Case	Decision
Double approval	No-op, not an error. A duplicate is overwhelmingly a retry after an uncertain outcome, and with Met terminal (#17) there's no state to protect. Erroring wouldn't catch the mistake people actually fear — approving the wrong milestone is a different call that succeeds regardless. Auth still checked first; no second event, so the indexer's fold never sees one approval twice.
Non-standard tokens	Store the measured balance delta. True by construction for any asset, one extra read. Fixes fee-on-transfer completely; rebasing stays unsupported, since no creation-time measurement binds a balance that moves afterwards. Resolves threat-model T4.
Archived entry	The contract never runs. Called directly, the transaction fails at the host level on the footprint — there is no contract branch to write and none could exist. An SDK obligation, not contract behaviour.

One correction to merged work

The asymmetry note added in #26 justified treating two cases differently on the grounds that the lifecycle diagram drew no arrow for either. That evidence turned out to be worth nothing on its own — the same missing arrow has now produced opposite answers for the two cases that leaned on it. The diagram was incomplete, not eloquent. Note rewritten to say so.

Changes

• docs/specs/behaviour.md — 3 new scenarios, 2 UNDECIDED placeholders replaced with real ones, Undecided cases → Resolved cases with the reasoning kept
• docs/architecture.md — lifecycle arrow; SEP-41 TODO resolved
• docs/concepts.md — cancel-after-end rule stated
• docs/research/threat-model.md — T4 status → Mitigated

Next in Track A: #33.