security: add runtime kill switch for the managed-skills reconciler

[pjdoland]

Summary

The admin guide currently documents that setting `skills_management_policy = force-off` (or `NBI_SKILLS_MANAGEMENT_POLICY=force-off`) will "suppress the managed-skills reconciler," but also concedes the suppression "takes effect on JupyterLab server restart" and that a live config-reload won't stop a reconciler that's already running. For an incident-response kill switch (compromised manifest URL, leaked managed-skills token), needing a server restart is too slow.

This PR adds two non-restart paths to stop the reconciler.

Solution

1. HTTP kill switch. New endpoint `POST /notebook-intelligence/skills/reconciler/stop`. Authenticated with the standard Jupyter session token. Returns `{"stopped": true, "was_running": }` so callers know whether the call actually interrupted work. Idempotent: a second POST after the reconciler is already stopped returns the same success shape, so admins can script the call across pods without special-casing already-stopped pods.

The endpoint is deliberately not gated by the Skills management policy. Inheriting from `SkillsBaseHandler` would mean the policy gate returns 403 in the exact `force-off` state where the kill switch is supposed to fire. A test pins this contract structurally (`SkillsBaseHandler` not in the MRO) so a future refactor can't silently re-introduce the deadlock.

2. Per-cycle env-var recheck. The reconciler's background loop now reads `NBI_SKILLS_MANAGEMENT_POLICY` at the top of each iteration via a new `_policy_force_off()` helper. If force-off is observed, the loop self-stops and logs. Latency is bounded by the cycle interval (default 24h), so this is the slow path for deployments that don't or can't call the HTTP endpoint. Adds one env-var read per cycle; zero ongoing cost.

A new `SkillReconciler.is_running()` helper supports the new endpoint's `was_running` payload field. `AIServiceManager.handle_stop_request` continues to call `reconciler.stop()` at shutdown; double-stop is safe and the early self-stop leaves `_thread` non-null so the shutdown join is harmless.

Testing

Eight new pytest cases across two files:

• `TestPolicyForceOffStop`: force-off at start prevents any reconcile pass; force-off mid-loop stops before the next pass; user-choice leaves the loop running; case-insensitive policy parsing including the `force_off`-vs-`force-off` underscore-vs-dash typo guard.
• `TestBackgroundThread::test_is_running_reflects_thread_state`: `is_running()` returns False before start, True during run, False after stop.
• `TestSkillsReconcilerStopHandler`: idempotent in both running and stopped states, returns the correct `was_running` value, and a structural MRO assertion pinning the deliberate gate-bypass.

`pytest tests/` (730 passing), `jlpm tsc --noEmit`, `jlpm lint:check`, `jlpm jest` (154 passing). All four green.

Six-agent review applied: added the MRO contract test, added the no-live-restart and per-tenant trust notes to the admin guide, added a clarifying comment at the route-registration site.

Risks / follow-ups

• No live restart of the reconciler. Once stopped, only a server bounce re-enables it in the same pod. Intentional: a kill switch another script could flip back on isn't a kill switch. Documented as a sharp edge.
• Per-tenant trust posture. The endpoint authenticates with the user's Jupyter session token, not an admin claim. In hub deployments where the pod owner is not the policy admin, a tenant can stop their own pod's reconciler. The reconciler is per-pod, so this only affects that user's managed-skills delivery. Documented.
• Capabilities surfacing. The Skills panel does not currently show a "reconciler stopped" status indicator. Worth a follow-up so users can verify the kill switch worked from the UI, but not load-bearing for this PR.