KillSwitchActivation: record the operator in a structured field, not free text

[GodSpeed313]

Post-GO engineering debt. Not a GO-1 prerequisite — recorded per the operator ruling of 2026-08-05 during the GO checklist §A2 review, so it is not lost.

Observation

KillSwitch.activate_manual(operator=...) and KillSwitch.clear(operator=...) both take an operator argument, but KillSwitchActivation has no operator field. The identity is folded into the free-text detail:

mode                   = 'manual'
trigger                = 'operator_command'
timestamp              = <utc-timestamp>
affected_action_class  = '*'
detail                 = 'operator=operator GO checklist section A2 row 5 exercise - no incident'
extra                  = {}

(moltbook/transport.py - KillSwitchActivation at :427, activate_manual at :480, clear at :557.)

Recovering who engaged or cleared the switch therefore requires parsing a string that also carries unrelated operator commentary.

Why it matters after GO

For manual inspection this is workable - the record is human-readable and the information is present. It is weak for structured auditing: any downstream tooling that wants to report on kill-switch activations by operator has to string-parse detail, and the operator= prefix is a convention enforced only by the two call sites that build the string.

The kill switch is the mechanism that halts a live deployed agent. Its activation log is the audit record of that intervention.

Definition of done

• KillSwitchActivation carries a dedicated operator: str | None field - None for automated triggers, populated for the manual/clear paths.
• detail keeps only operator-supplied commentary; the operator= prefix convention is removed from the constructed string.
• Automated triggers are unaffected: they have no operator, and must not acquire a synthetic one.
• Existing kill-switch tests updated; test_structured_activation_audit extended to assert the new field on both the manual and the automated paths.
• tools/go-checklist-exercises/a2_dry_run_and_kill_switch.expected.txt regenerated (its --check mode will fail until it is - that is the intended signal).
• The section 10 kill-switch part of docs/m7_moltbook_transport_boundary_and_deployment_spec.md describes the audit record fields accurately after the change.

Scope discipline

Schema and audit-record change only. No change to what engages the switch, what it blocks, the operator-only re-enablement rule, the dormant section 14 triggers, or the captcha_suspension_risk threshold.