Honour operator rules on the Slack submit path #19

Part of #6.

The keyword-rule matcher from #16 (closed by #16 PR) short-circuits RAGEngine.generate_response, so POST /api/ask returns a pinned canned answer without retrieval or generation. The Slack path does not. SlackBot handlers call RAGEngine.submit_slack, which builds a Pi Durable payload through _agent_payload and never checks rule_engine, so a pinned answer never fires for mentions, DMs, or the /wingman command - the main way users talk to Wingman.

This slice covers the Slack submit path only:

• submit_slack checks the operator rules before retrieval. On a match it skips vector search and submits a payload carrying the pinned answer, with the operator-rule source recorded, keeping the existing request id, conversation id, and Slack delivery target.
• The Pi Durable worker delivers a payload that carries a pinned answer without calling the model, so delivery stays durable, retried, and idempotent through the existing job outbox instead of adding a second Slack posting path in the bot.
• Reusing a request id with a different pinned answer is treated as a conflicting reuse, like a different question already is.
• Tests cover the matched and unmatched Slack paths in the backend, and pinned-answer delivery without model generation in the runtime.

Out of scope for this slice: new rule types, mutable or fetched-source rules, dashboard rule editing, and any live Slack verification. Verification is offline against mocks and fixtures only - no Socket Mode, no live workspace token.