R1-063: Add user project import ban test harness

[1sgtpepper]

Checklist

• This fits the named release or area.
• This is small enough for one focused PR.
• Relevant checks are listed below.

Summary

• Current state: main is a static scanner and CONTRIBUTING forbids execution/network/import shortcuts, but the architecture-specific execution, network, import-trap, path/resource, and budget interdiction harnesses are incomplete.
• Goal: Add user project import ban test harness through Static-analysis safety, resource policy, and sandbox rails. Inputs are limited to analysis entry point plus hostile fixture or interdiction guard; use a hostile fixture or monkeypatch/import trap that would fail if the forbidden action occurs; absence of a call in one code path is not sufficient evidence.

Affected Area

Release: R1 foundations
Area: tests

Dependencies:

• R1-062

Change

Required change:

• Input boundary: The change must accept only analysis entry point plus hostile fixture or interdiction guard.
• Required output: The change must produce executable "user project import ban test harness" evidence that reaches the real path and fails under its negative control.
• Use a hostile fixture or monkeypatch/import trap that would fail if the forbidden action occurs; absence of a call in one code path is not sufficient evidence.
• Fail closed and explicitly when a path/resource/budget policy is violated.
• Exercise the real selected-kernel or named compatibility entry path; a direct unit call or broad mock that bypasses the owning seam is insufficient.
• Include a positive case, boundary/edge case, and negative control that fails when the guard or expected result is removed.

Include:

• The named fixture/assertions and one meaningful negative control only.
• The real selected-kernel or compatibility entry path named by R1/R2; no bypass-only mock proof.

Out of scope:

• Do not include unrelated cleanup, a new diagnostic rule, or a second architecture owner.
• Do not change CLI/API signatures, diagnostic code, severity, text, spans, ordering, schemas, baseline/suppression behavior, discovery, or file ordering unless this issue explicitly owns a versioned SchemaHost migration.

Likely files:

• tests/security/
• tests/test_security_contracts.py
• src/scieqlint/io/
• pyproject.toml
• src/scieqlint/workspace/resources.py
• src/scieqlint/kernel/budgets.py
• tests/notebooks/

Test Notes

Acceptance checks:

• The fixture exercises the declared input boundary and verifies the required output.

• Assertions cover every requirement above, including one edge case and one meaningful negative control.

• The evidence reaches the named production/compatibility path and is deterministic under repeated or shuffled-equivalent input where applicable.

• Create or extend tests/test_security_contracts.py and run python -m pytest tests/test_security_contracts.py -q.

• Record the negative control: the exact assertion/guard whose deliberate removal makes the new test fail.

• Evidence: The hostile action is trapped on the real analysis path.

• Evidence: A policy/resource violation fails closed with explicit evidence.

• Run lint-imports, python -m ruff check src tests, and python -m pyright for changed Python/import configuration.

Compatibility notes:
No public behavior change. Any public behavior drift needs a linked SchemaHost/versioned compatibility issue.