Specify kill-switch protocol: scope, testing, and sub-agent/multi-agent coverage

## Description

Epic 6's acceptance criteria state "a kill-switch protocol is defined," but don't yet specify what "stopped" means, how it's tested, or whether it reaches sub-agents and scheduled/async actions.

## Source

Krav 5 "Nødstopp tilpasset konsekvens" and Krav 15 "Nødstopp på systemnivå": a kill-switch that only stops the coordinator but leaves sub-agents running does not satisfy the requirement.

## Business Goal

A kill-switch that doesn't fully work is a false sense of safety. This is the control BOD leadership will rely on to contain an agent that's causing harm, so it needs to be specified precisely enough to test.

## Acceptance Criteria

- Documented protocol defines "safe state" (tokens/keys revoked, tasks halted, no auto-restart without human approval) and the layered response (throttle → pause → full stop).
- Protocol explicitly requires sub-agents and scheduled/async tasks to be covered, not just the top-level agent process.
- A test procedure exists and has been run at least once against a real or reference agent, with the result logged.
- Any team registering a Class 2–3 agent documents how their kill-switch meets this protocol.

## Dependencies

Builds on #74's "kill-switch protocol" acceptance criterion. Coordinates with the mandate-delegation-limits issue for multi-agent systems.