Pytest diagnostics bridge and the MolSysSuite policy layer

What — How SMonitor diagnostics should participate in a pytest run without
becoming a second test reporter, and what a shared MolSysSuite policy
layer would own.
How — A bridge that correlates SMonitor events with the pytest node, phase and
xdist worker they occurred in, initially inside SMonitor
(smonitor.pytest_plugin or a smonitor[pytest] extra), contributing
evidence to pytest-receptor rather than replacing its collector.
Why — A runtime diagnostic raised during a test currently carries no link to
the test that raised it, so a CI failure and the incident behind it are
two unrelated records.
Record — devguide/pending_proposals/pytest_diagnostics_bridge_and_molsyssuite_policy.md

Post-1.0 by design. Two things have changed since it was written and it should be
re-read against them before any implementation decision:

• uibcdf/molsyssuite now has a real conformance policy, rolling out across
  member repositories. The document speculates about a future
  pytest-molsyssuite; part of that question may already be answered, and the
  ownership boundaries it proposes may need redrawing.
• A warning-count gate needs a deterministic test distribution, measured in
  devguide/warning_baselines_under_parallel_test_runs.md. Any baseline this
  bridge defines has to account for it.

Start with devguide/pending_proposals/pytest_diagnostics_bridge_and_molsyssuite_policy.md, then compare it with the current uibcdf/molsyssuite conformance policy and devguide/warning_baselines_under_parallel_test_runs.md. Determine the ownership boundary for an SMonitor-to-pytest bridge and its warning-count baseline under parallel runs; done means the implementation decision and affected responsibilities are documented clearly.