hal2Bayes: explain the estimate, and let a rule be an AND

[flic]

Tuning a Bayes node meant reading a probability and guessing what produced it. The snapshot on
output 2 already carried the raw material — activeRules, terms and fsm — but not in a form
anyone could use: rules appeared as internal ids, contributions were in log-odds while the whole
editor speaks share of the way to on in percent, the three fields had to be cross-read against
each other, and only contributing rules appeared at all. The question while tuning is usually
why a rule is not firing, and nothing in the snapshot answered it.

One rules array

The three fields are replaced by one array listing every configured rule, every time, with a
status saying which case it is in.

{ "p": 0.86, "logOdds": 1.86, "share": 108.4, "binary": true, "held": false,
  "rules": [
    { "label": "While Hall Rörelse · Motion is true",
      "status": "contributing", "share": 73.8, "logOdds": 2.303, "value": true },
    { "label": "When Ytterdörr · Contact is true on a full cycle and Hall Rörelse · Motion is true",
      "status": "waiting", "step": 2, "steps": 2, "deadline": 47 },
    { "label": "While Kontor Sensor · Temperature > 25",
      "status": "condition-false", "value": 23.4 }
  ] }

contributing, fading (with age and half-life), waiting (with step and deadline), armed,
condition-false (with failedStep), no-value, injected, never-fires. Each entry carries
what its source reads right now, so a false condition can be seen rather than inferred.

Contributions are reported as shares of the way from the prior to the on-threshold — the unit
the rule bars and the summary already use, so what you tuned is what you read back. Log-odds are
additive, so the shares are too: the contributing ones sum to the snapshot's own share, pinned by
a test, because a report that does not add up is a report that lies.

The report is built in the same pass that computes the estimate, so a rule cannot be described as
contributing unless its weight really went into the log-odds.

Labels are derived from the steps and phrased as the editor phrases them. The phrasing lives in a
UMD module (resources/bayes-label.js) so the editor can adopt it later; name resolution stays in
the node, the only layer that can reach RED.nodes.

A rule of only conditions is an AND

Found by using the report: a live rule sat at armed forever, and asking why exposed a real gap.

"While it is 09:00–10:00 and the terrace is above 100 lux" could not be expressed. Anything
with more than one step went to the sequence machinery, which is driven by edges — and a condition
is not an event, so the first step never completed. The editor warned about it, but the only way
out was to rewrite the rule as something that meant something else.

A rule whose steps are all conditions is now continuous: one weight that applies while every
condition holds at the same time. isContinuous grows from "a lone level check" to "every step is
a level check", and the label module and the editor follow, so such a rule reads "While A and B" in
all three places. A rule that opens with a condition but waits for an event later is still
unreachable and now says so as never-fires rather than sitting at armed looking merely idle.

The editor stops offering what such a step cannot use: in an AND there is no previous step to be
"soon" after, so later steps offer only "now". A step that is already a condition is narrowed with
a notice, since the behaviour is identical either way; an event after a leading condition is left
alone — that is a broken rule rather than an AND, and coercing it would quietly turn "then the door
opens" into "and the door is open".

A crash on the way out

hal2Bayes has a regex operator but never forced the matching value type, and COMPARE.regex
calls b.test — so a rule saved as regex-against-a-string threw a TypeError out of evaluate()
and took the whole evaluation with it, every other rule included. Reachable from the editor until
now.

The value types are narrowed to what each operator can use, following what hal2Event and hal2Gate
already did rather than inventing a third behaviour. And conditionMatches now guards the
comparison as well as the conversion: a condition that cannot be evaluated has not matched, and its
neighbours still run.

Testing

249 passing. The new ones cover every status, that every configured rule appears exactly once in
every state, that the shares sum to the total, the AND semantics at each edge, never-fires, and
the regex crash.

Verified against the running instance: labels rendered from the live configuration, the rule that
prompted this simulated through all four combinations of its two conditions, and waiting with a
counting-down deadline plus fading decaying per tick observed on a real node.