fix: Do not load the native extension to build an empty rules list

[leongdl]

The gap #341 left

#341 stopped import openjd.sessions from loading the native
openjd._openjd_rs extension. But Session.__init__ calls
_build_expr_host_rules() unconditionally, and that imported openjd.expr —
a facade over the extension — before checking whether there was anything to
convert. With no path mapping rules it imported the engine, iterated an empty
list, and returned [].

So a worker that never evaluates an EXPR expression still loaded the extension on
its first session. 49d1804 moved the load from import time to
first-session time rather than eliminating it. Caught by a reviewer reading the
call site; confirmed by measurement:

import openjd.sessions              -> rs_loaded=False   (#341 holds)
Session(...)  no rules, no EXPR     -> rs_loaded=True     _expr_host_rules == []

The fix

Return [] directly when there are no rules — byte-identical to what the loop
produced.

It must stay [] and not None: the session is still host scope, so
apply_path_mapping() has to remain available with an empty rule set. Seeding
[] is free — SymbolTable stores expr_host_rules untouched as
Optional[list[Any]] and only crosses into Rust at evaluation time in
_expr_support.symtab_to_expr_values. Verified that assigning None, assigning
[], and running a full non-EXPR resolve all leave the extension unloaded.

Audited every load path, not just this one

Rather than grepping for imports, I installed a sys.meta_path finder that
records the stack at the moment openjd._openjd_rs is first imported, and ran
each flow in its own fresh interpreter.

Flow	Before	After	Expected
import openjd.sessions	pure	pure	pure
Session() no rules	LEAK	pure	pure
Session(path_mapping_rules=None)	LEAK	pure	pure
non-EXPR run_task end to end	LEAK	pure	pure
non-EXPR enter_environment	LEAK	pure	pure
non-EXPR argument resolution	pure	pure	pure
non-EXPR optional-int resolution	pure	pure	pure
Session(path_mapping_rules=[rule])	loads	loads	loads — see below
EXPR evaluation	loads	loads	loads
openjd.sessions._v1	loads	loads	loads

All four leaks traced to the same single frame:

openjd/expr/__init__.py <- _session.py:1657 in _build_expr_host_rules <- _session.py:476 in __init__

After the fix every non-EXPR flow is clean and the only remaining loads are the
three that should load.

Known limitation, asserted rather than implied

A session with real path mapping rules still loads the extension, because the
rules must be converted into openjd.expr.PathMappingRule engine objects to seed
host context. openjd-sessions cannot avoid that alone — closing it needs
openjd-model to accept unconverted rules and convert them at the Rust boundary it
already crosses.

test_path_mapping_rules_do_load_the_extension pins the current behaviour so a
future fix is noticed here instead of passing silently.

This matters in practice: a worker with path mapping rules configured — the
common case — still loads the extension on its first session. This PR fixes the
no-rules case, which covers the CLI default and most tests, and narrows the
remaining exposure to one well-understood site. It does not deliver "a non-EXPR
worker never loads the extension" on its own.

Correcting my own earlier audit

When I audited crossings for #341 I classified this site as "already
function-local (lazy)" and moved on. Lazy is not conditional. A
function-local import still runs unconditionally the moment its function is
called, and this one is called from __init__. The existing purity tests covered
import time plus one runtime path, so nothing would have caught this.

Testing

Mutation-checked: 4 mutants, 0 survivors. Neutralising the fast path,
returning None instead of [], firing it for every session, and inverting its
condition are each caught by a named test.

913 passed, 39 skipped, 16 xfailed
ruff clean · black clean · mypy clean · mypy --platform win32 clean

[wyongzhi]

Might be a parity gap, related to this area (not caused by this PR): rules added after construction are honored by Rust but not Python v0. Rust's extend_path_mapping_rules rebuilds the expr library (session.rs:759); v0 has no extend API, so callers append to _path_mapping_rules directly — live consumers see the new rules, but _expr_host_rules (built once at _session.py:458) doesn't, so apply_path_mapping() silently resolves against stale rules. Job-attachment style workflows always add rules post-construction, so this will bite once EXPR templates use them together. Not sure how you think about it

[wyongzhi]

Might be a parity gap, related to this area (not caused by this PR): rules added after construction are honored by Rust but not Python v0. Rust's extend_path_mapping_rules rebuilds the expr library (session.rs:759); v0 has no extend API, so callers append to _path_mapping_rules directly — live consumers see the new rules, but _expr_host_rules (built once at _session.py:458) doesn't, so apply_path_mapping() silently resolves against stale rules. Job-attachment style workflows always add rules post-construction, so this will bite once EXPR templates use them together. Not sure how you think about it

Above comment is non-blocking, so I would approve this one and if needed we can discuss more here

[github-actions]

The empty-rules fast path changes behavior for one case: no rules + openjd.expr unavailable (pre-EXPR openjd-model, or the native extension not built for the platform).

• Before: the try/except ImportError ran even with no rules, so this case returned None.
• After: it returns [] unconditionally.

Two things worth confirming:

1. The docstring is now stale — it still says the method "returns … None when the engine bindings are unavailable (pre-EXPR openjd-model)", but with no rules that path is no longer reachable; None now only happens with rules present + bindings missing.
2. _expr_host_rules is assigned straight onto symtab.expr_host_rules (line 1621) and crosses into Rust at evaluation time. Within this repo nothing distinguishes None from [] (no is None checks on it), so this looks safe — but please confirm openjd-model's SymbolTable / the Rust boundary treats an empty-list host-rules context the same as an unset/None one for a pre-EXPR build, so seeding [] there cannot trigger host-context construction that None previously avoided.

If both hold, a one-line docstring tweak so the None-return note reflects that it is now the rules-present case only would keep it accurate.

[github-actions]

run_task resolves the command via shutil.which (_win32/_locate_executable.py:66), and on Windows echo is a cmd.exe builtin with no standalone echo.exe on PATH — so shutil.which("echo") returns None and the launch raises RuntimeError("Could not find executable file: echo"). The probe then exits non-zero and _run_probe's assert completed.returncode == 0 fails.

The rest of this file goes out of its way to support Windows (see _probe_python), and the existing suite already handles exactly this: test_runner_base.py:835 uses "echo" if is_posix() else "cmd.exe". This end-to-end test uses echo unconditionally, so test_running_a_non_expr_task_stays_pure_end_to_end looks like it will fail on Windows. Consider selecting the command per-platform (e.g. cmd.exe /c echo hello).