forms: FlowSession::set<>'s @brief promises handler forwarding and in-flight coalescing that its own body says do not happen

[Yaraslaut]

Found while fixing morph#355, and reported to the sprint manager rather than
absorbed into that ticket. Both defects are in one doc block, so they are one
ticket: splitting them would put two branches on the same lines.

1. The @brief promises behaviour the body denies

FlowSession::set<>'s published @brief (include/morph/forms/flows.hpp:239-241):

Sets one field of the current step's draft and forwards it to the handler's
ordinary set<> (auto-fires when the step's ActionValidator is ready,
exactly as a standalone form).

The body, eleven lines below, says the opposite in its own comment
(flows.hpp:262-266):

The readiness gate that used to live in the handler's draft machinery lives
here now: the flow already owns the draft, so it can decide when the step is
complete and dispatch it itself. Note there is no in-flight coalescing —
each ready set<> dispatches, where the old handler-side draft collapsed
patches landing during a flight.

Two claims in the @brief are false:

• "forwards it to the handler's ordinary set<>" — it does not forward
  anywhere. flows.hpp:256-270 writes std::get<A>(_drafts), checks
  ActionValidator<A>::ready(draft) itself, and calls its own fireStep<A>.
• "exactly as a standalone form" — the body names the exact way it is not:
  a standalone form's handler-side draft coalesced patches arriving during a
  flight; this does not.

The coalescing one is what makes this worth a ticket rather than tidying. A
caller reading the published documentation will expect keystroke-rate set<>
calls to collapse into one dispatch while a request is in flight. They do not —
each ready set<> dispatches. That is a difference in request volume and in
observable ordering, promised by the docs and not delivered.

2. BridgeHandler::set<> does not exist

The same block cites it twice — flows.hpp:184 and the @brief at :239:

the reactive draft/subscription primitive (BridgeHandler::set<> /
subscribe<>, bridge.hpp)

BridgeHandler has no set<> member. Its only set-like members are
setDefaultSession, setException, setExecuteDeadline, setPrincipal,
setReconnectHandler, setSession and setValue — verified by
grep -oE '\bset[A-Z][A-Za-z]*' include/morph/core/bridge.hpp | sort -u.

This is the same defect class as morph#355 and morph#349, under a different
name, so neither of their fixes touches it. Sibling sites outside this file are
tracked separately (registry.hpp and examples/bank) — see the issue filed
alongside this one.

Verification status: reproduced

Read on master e675253a. flows.hpp:239-241 and :262-270 quoted verbatim
above; the BridgeHandler member list is from the grep named above. The
contradiction is visible in a single 35-line span of one file.

Not verified: whether any caller currently depends on the coalescing the
@brief promises. If one does, this stops being a documentation defect and
becomes a behavioural one, which is a different and larger ticket.

What would close this

1. The @brief describes what FlowSession::set<> does: owns the draft,
   evaluates readiness itself, dispatches via fireStep<A>, and does not
   coalesce in flight. The absence of coalescing is stated in the published
   documentation, not only in an implementation comment.
2. Both BridgeHandler::set<> citations name something that exists, repointed
   rather than deleted so the explanation they carry survives — the standard
   morph#355 applied.
3. git grep "BridgeHandler::set<>" returns nothing in
   include/morph/forms/.

Blocked by morph#355 — its PR #414 edits flows.hpp:184-191, the same doc
block.

[Yaraslaut]

Widening this ticket: five more sites in the same header, one of them a different defect

Found by the D framework lane while fixing morph#418 (the sibling
BridgeHandler::set<> sweep in include/morph/core/), and verified by me
against origin/master be478df1 before recording.

The reason to widen rather than file separately: #418's branch now asserts, in
docs/spec/core/bridge.md and registry.md, the opposite of what
include/morph/forms/flows.hpp still says. Fixing only the two sites this
ticket originally named would leave the header contradicting the specs that
describe it.

The new one — a renamed symbol, not a removed one

flows.hpp:290 cites subscribeCurrent(). It was renamed beginStep().

$ git grep -c "subscribeCurrent" origin/master -- '*.hpp' '*.cpp'
(no matches)
$ git grep -n "beginStep" origin/master -- include/morph/forms/flows.hpp
214:        beginStep();
296:            beginStep();
315:        beginStep();

This is a repointable citation — the function still exists under a new name —
so it should be repointed, not deleted.

The rest, same class as this ticket's originals

Site	Cites
flows.hpp:208	"BridgeHandler's own no-errSink default" — no such default and no such name
flows.hpp:302	"the handler's own per-action draft" — the draft is FlowSession's, in std::tuple<Steps...>
flows.hpp:219-221	justifies the stop-token by "unsubscribe() only removes the sink from the handler's map"
flows.hpp:366-368	justifies the stale-reply guard the same way

The last two matter more than a stale name: the guards are correct, but the
stated reasons name a mechanism the class does not use — FlowSession never
subscribes at all. A reader deciding whether a guard is still needed would be
reasoning from a false premise.

errSink is worth noting on its own. It exists nowhere as a symbol — only in
flows.hpp:208's comment, in docs/spec/core/bridge.md (being removed by
#418), and in a TEST_CASE name at tests/test_flows_apps.cpp:226. That test
name is T tests' lane and is tracked separately.

Also in scope, to keep the spec pairing coherent

docs/spec/forms/forms.md:1337 and :1954 — "the reactive set<> gate". These
are forms.hpp's spec counterpart and belong with this ticket rather than with
#418, so that include/morph/forms/** and docs/spec/forms/** change together
and the Header ↔ spec sync gate stays satisfied.

Updated acceptance

Everything in the original clause, plus:

1. flows.hpp:290 names beginStep().
2. git grep -n "subscribeCurrent\|errSink" include/morph/forms/ returns nothing.
3. The stop-token and stale-reply guards at :219-221 and :366-368 are
   justified by what FlowSession actually does, not by a subscription it never
   makes. The guards themselves stay — only their stated reasons are wrong.
4. docs/spec/forms/forms.md:1337 and :1954 no longer describe a reactive
   set<> gate on BridgeHandler.