Read `raise` as an expression, and measure whether that makes the analyzer noisier

This is the clause's THIRD position. 0.4.23 handled it on a FUNCTION -- the
signature annotation and a function type's return annotation. The statement that
actually performs the raising had never been implemented, and it was read as an
ordinary identifier, so every raise statement reported `undefined name 'raise'`
-- a confidently false positive about code that compiles:

    // moonbit-community/proton 0.3.4 facade_app_metadata.mbt:82
    guard config.package_config() is Some(package_config) else {
      raise MissingPackageMetadata
    }

A MEASUREMENT REDIRECTED THIS RELEASE, and it corrected the previous release's
own conclusion. When 0.4.23 finished with actionable up, I classified every
UndefinedName and concluded they were enum/suberror/derive constructors falling
outside the analyzed subset. Classifying them showed the biggest bucket was not
constructors at all: of roughly 70, **65 were the literal name `raise`**.
Constructors were a real but small tail, about 7.

Scale (vendored .mooncakes excluded): 585 sites across 54 files of proton,
427 / 90 of async, 180 / 16 of moonbit_image, 15 / 9 of moonbit_labeler,
6 / 1 of proton_contract.

Settled against `moon check` first, all zero errors: the five payload-carrying
forms, and -- newly checked here -- a BARE `raise` with no payload at all, which
is valid in three positions (alone in a body, at the end of a body, closing a
nested block with no semicolon).

A new `SRaise(Expr?)` node rather than `SReturn`, because three lenses read a
raise wrongly as a return:

  - `Infer::scan_returns` has `SReturn(Some(e)) => acc = ty_join(acc, ty_of(e))`,
    which would join the error CONSTRUCTOR's type into the function's return
    type;
  - `Interp`'s `SReturn` evaluates the operand and pushes it into `ret_vals`,
    inventing a return value `raise` never produces;
  - only the divergence is shared, and that is exactly what `SRaise` keeps.

The payload IS walked and type-checked -- `nosuchfunction` inside
`raise E(nosuchfunction())` still reports -- but it is NOT evaluated, because
everything after a terminator is dead and evaluating a discarded expression
could only perturb the abstract value stack. One test per lens pins that.

MEASURED THE NOISE BEFORE COMMITTING. The behaviour lens explores an if's
branches one after another in the same `Interp`, so flow state leaks between
them: a terminating branch makes everything after the `if` look dead. If that
were real, this release would have traded 56 false positives for a new batch.
Across 12,428 files `Unreachable` went 0 -> 0, and **nothing new appeared in
any family**: all 65 `undefined name 'raise'` findings are gone and actionable
fell (async 22 -> 19, proton 103 -> 100, moonbit_image 3 -> 0).

The flow leak is nonetheless REAL and reproduces with no `raise` involved --
`guard g is Some(v) else { return 0 }` followed by `return v` reports `return v`
as unreachable, because the else terminates, the then branch (empty, being how
`guard` is modelled) does not, and the else's flow won the race. Recorded
honestly and NOT fixed here: it fires on 0 of the six corpora and changing it
means changing the behaviour lens's branch-merge semantics, which is a
different change. Also recorded: `enum_ctors` harvesting is wired only to
`enum`, not suberror/derive, and constructor names living in another package's
.mbti (proton's `OperationFailed`) never reach `IfaceSymTab` at all. That is
where the remaining 7 come from.

Mutation gate: 7 mutations, 7 killed, 0 survived, every restore verified
byte-identical. Three of them survived the FIRST version of the test file, all
for one reason worth recording: **when the payload is not parsed it does not
disappear, it becomes the next statement.** `raise E(nosuchfunction())` is then
read as `SRaise(None)` followed by the expression statement
`E(nosuchfunction())`, and the same two undefined names still land on the same
line and still merge into one -- every count-based assertion passes either way.

  - M2 first tried separating them by the behaviour lens not evaluating the
    payload; that failed too, because an orphaned payload follows a terminating
    `SRaise(None)` and so is reported unreachable rather than executed. What
    finally separated them was the ANCHOR LINE: with the payload attached the
    dead statement is `return 1` on line 6; orphaned, it is the payload itself,
    still on line 5. Same count, same family, same lens -- and the line is
    exactly the claim being made.
  - M4 failed for a second reason: every payload before it was a call to an
    UNKNOWN name, and a call to an unknown function has no signature to check
    arguments against, so `ty_of` returned early and the payload was never
    really looked at. Replaced with an expression the type lens checks on its
    own, `raise 1 + "a"` (settled valid; int + str is an OperatorMismatch) --
    a binary operator cannot be skipped for want of a signature.
  - M7 failed because the file had no bare `raise` fixture at all: the function
    named `bare` writes `raise E`, which HAS a payload.

Tests: 386 js / 458 wasm / 386 wasm-gc (12 new). moon check and moon fmt --check
clean.