fix(compiler): an operator refuses a possibly-None operand, the way attribute access already does

[SandeepaHWP]

Fixes #8547

What was wrong

x + 1 where x: int | None passed jac check clean and then raised
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int' at runtime.
The same value on the attribute path was rejected:

def f(x: int | None) -> int { return x + 1; }            # accepted
def h(s: str | None) -> int { return s.upper().len(); }  # E1099, correctly

Why

Member lookup requires every member of a union to carry the attribute, and that
all-members rule is exactly what produces the E1099 above. Magic-method
resolution over a union does the opposite: it walks the members and succeeds as
soon as one of them answers, dropping the ones that do not. So
(int | None).__add__(int) resolved through the int member and typed the whole
expression int, with NoneType contributing nothing and no diagnostic.

The gap was wider than the reported case:

expression	operand types	before
x + 1	int | None, int	accepted
y + x	int, int | None	accepted
x += 1	int | None, int	accepted
x + y	int | None, int | None	rejected, but as "no matching overload for __add__"

The change

Operator sites now apply the same all-members rule the attribute path applies, and
report it as a new E1135:

error[E1135]: Operator "+" has a possibly-None operand of type "int | NoneType"
  --> repro.jac:2:12
help: A `T | None` value has no arithmetic, bitwise, or shift behavior on its None
      case, so the operator would crash at runtime. Guard the value first, e.g.
      `if x is not None { ... }`. Equality (`==`, `!=`) and `is None` checks work
      on the optional directly and need no guard.

Covered: arithmetic (+ - * / // % **), bitwise & and ^, shifts << and >>,
and @, in both plain and augmented (+=) form, on either operand.

Deliberately not covered:

• | doubles as type-union syntax, so it stays out of the operator set.
• ==, !=, is, is None and in operate on an optional directly and parse as
  comparisons rather than binary expressions; they are untouched.
• A union carrying any absorbs the operator, as any does everywhere else.
• Augmented assignment reads its target through the narrowing walk, so a guard on
  the target counts: if x is None { x = 0; } x += 1; stays clean.

The deeper cause, and why it is not in this PR

The permissive union rule lives in one place: magic-method resolution answers
whenever any member of the union answers. That permissiveness reaches every
operation routed through it, not only operators. All of these still accept an
un-narrowed optional on the server lane today:

• for v in maybe_list where maybe_list: list[int] | None
• d[k] where d: dict[str, int] | None
• await maybe_coro, with maybe_cm { }, a, b = maybe_tuple

(Subscript and ordered comparison are caught on the native lane only, by
E1121.) A heterogeneous non-None union has the same hole: v + 1 on
int | str is accepted because the int member answers.

Flipping the shared resolver to require all members would close all of that in one
move, but it changes iteration, subscript, await, with and unpacking semantics
simultaneously, and each of those wants its own diagnostic and its own fixture
pass. That belongs in a separate, deliberate change rather than arriving as a side
effect of a PR about operators. The shape this PR follows is the one already in the
codebase: attribute access does its own union walk and raises its own code instead
of routing through a shared strict helper.

Tests

jac/tests/compiler/passes/fixtures/checker/checker_optional_operator_operand.jac
holds 16 fail_ functions (one operator each, plain and augmented, optional on the
left, on the right, and on both) and 9 ok_ functions covering is not None,
early return, truthiness, ternary fallback, a plain non-optional operand, a
non-optional union, equality against None, an any operand, and an augmented
assignment after a guard. The regression test asserts exactly 16 E1135 and no
cascade behind them, and that no ok_ function reports anything.

Stacked on #8957

This branch sits on top of #8957, which fixes an unrelated narrowing bug that
this diagnostic surfaced: an == <int literal> guard erased the int arm of an
optional, so correctly guarded code reached an operator looking un-narrowed.
Review or merge that one first; the diff here is the operator work alone once
it lands.

Three sites the check found were real, and are guarded in the last commit
rather than suppressed: an ast node's end_lineno (int | None) had one
added to it, the telemetry aggregate read its totals back out of a
dict[str, JsonValue] instead of off the typed fields its own neighbouring
loop uses, and the format-cache tests joined paths onto a Path | None root
that the library asserts before the same join.