Use Little Canary SecurityPipeline in injection adapter - #1

Hi @samvitgersappa — this PR updates the CI security extra now that little-canary 0.3.5 provides a universal wheel, and adds adapter regression coverage. GitHub shows the PR workflow as action_required, so it has not run its checks. If approval is needed to run it, could you approve it when convenient?

Approved.

The fix is correct and I verified it end-to-end rather than relying on the description:

• The core claim checks out against the little-canary source: SecurityPipeline is the real export (CanaryDetector has never existed), PipelineVerdict.degraded exists in >=0.3.3, and the advisory fields/severity values the adapter consumes match the library exactly. SecurityPipeline() construction does no I/O and check() is blocking + stateless, so asyncio.to_thread is the right call and is safe under concurrency.
• Ran the suite locally: 38 passed (including the 14 new adapter regression tests) on the locked 0.3.5/current 0.3.6, and 14/14 adapter tests on the declared minimum 0.3.3. ruff check, ruff format --check, and mypy are all clean.
• CI change is sound — little-canary ships a universal py3-none-any wheel, so the old "no Linux wheel" comment was simply wrong, and the adapter tests will now actually run in CI.

Two tradeoffs I'm consciously accepting (flagging for the record, not blocking):

1. When the optional security extra isn't installed, every input now records a severity-3 screening_degraded event. This shifts the meaning of total_security_events/the security dashboards from "findings" to "screening status" — which is the point, but worth documenting so it doesn't read as a security alert.
2. prompt_injection severity is now 9/6/3 (high/medium/low) instead of a fixed 9.

Thanks for the thorough regression coverage and the docs update. This fixes a real silent no-op bug.