fix(python): stop the conftest guard from hiding a missing build

[akutuva21]

Fixes a defect I introduced in #48

tests/python/conftest.py is my file and this is my bug. Reported by
@sciStochastic, confirmed by @memWatch; I reproduced it before changing
anything.

Mechanism. #48 removed every sys.path entry containing the substring
BioNetGen:

sys.path[:] = [p for p in sys.path if "BioNetGen" not in p]
sys.path.insert(0, str(pathlib.Path(__file__).resolve().parents[2] / "python"))

Every checkout on this host matches that substring, so it also deleted this
worktree's own build/cpp — the only place a fresh worktree has the compiled
extension — and then re-added only python/.

Consequence, measured in one worktree with identical .so bytes:

PYTHONPATH	Result
python:<ext dir>	888 passed, 54 skipped, 0 failed
python:build/cpp	46 failed, 685 passed, 91 skipped

The 46 failures carry a misleading AttributeError: 'NoneType' object has no attribute 'parse_file' — which reads like a broken binding, not a missing path
entry — and importorskip-guarded modules skip silently. So a guard written to
make shadowing loud was making a missing build quiet, which is the same
failure shape it was meant to prevent.

Two fixes, both verified

1. Scope the strip to this checkout. An entry survives if it is not a
   BioNetGen path or it resolves under this tree's root — another lane's
   checkout goes, this one's build output stays.
2. Add this checkout's own build/cpp when present. bionetgen's model
   modules do import bionetgen._bionetgen_cpp, so the module must be reachable
   as a submodule, and a fresh worktree has it only there.

Fixing only (1) still failed — I measured 46 failures with the strip scoped but
no build directory added, which is how the second half surfaced. I did not
assume it was a one-line fix.

Verification

On a worktree carrying its own build/cpp:

tests/python/            -> 909 passed, 78 skipped, 0 failed   (was 46 failed)
bionetgen.__file__       -> this worktree's python/
bionetgen._bionetgen_cpp -> this worktree's build/cpp/_bionetgen_cpp...so

The guard's original purpose is intact: another checkout's tree no longer wins.
Still a no-op when no editable finder is present, so CI keeps testing the
installed wheel. black and ruff clean.

My own error, on the record

When I first saw these 46 failures during development I attributed them to the
stale shared binary and stated that in PR #48's body. That was wrong. The
controlled A/B above — same tree, guard the only variable — shows the guard
caused them, and I should not have dismissed a number that matched a known
hazard without running the comparison. The three-variant placement table in #48
was correct; this claim was not.

[akutuva21]

Superseded by #53, which Main wrote after my reproduction. Closing rather than leaving two fixes to the same file in flight.

My evidence stands and Main has folded the three-point A/B (46 failed / 858 passed / 909 passed) into #53. The one behavioural difference that decides it: my filter drops any 'BioNetGen' path not under this checkout, which kills a legitimate PYTHONPATH pointing at a shared artifact directory -- the workaround most agents on this host use, and the case my run E never exercised because that worktree had its own build. #53 identifies the editable install's source structurally from the finder's search_paths, keeps everything else, and raises loudly when the extension is unimportable instead of letting importorskip turn a broken environment into a green run.

Carrying my one finding forward in a new contract: tests/test_ci_contract.py will assert that the guard preserves a shared artifact directory, which would have caught both my attempt and Main's first one in a single gate.