#261 Side-Effect Atomicity: Implement Idempotency-Key for HTTP requests

## Problem Database state is atomic, but external side effects (e.g., tools.http.request) execute *before* the transaction commits. If a worker crashes post-execution but pre-commit, the retry will duplicate the side effect. ## Impact External systems (APIs, emails) may receive duplicate requests during failure scenarios. This is an at-least-once guarantee instead of exactly-once. ## Technical Details - Current flow: Execute HTTP request → Commit transaction - Failure scenario: HTTP succeeds → Worker crashes before commit → Retry sends duplicate request - Affected tools: tools.http.request, potentially tools.email.send ## Proposed Solution Enhance tools.http.request to automatically inject a deterministic Idempotency-Key header derived from: - ctx.workflow_run_id - step_name - attempt_number (optional, for retry tracking) Example: Idempotency-Key: {workflow_run_id}:{step_name}:{attempt} ## Implementation Steps 1. Add idempotency_key generation in tools/http_request.py 2. Auto-inject header unless explicitly disabled via skip_idempotency_key=True 3. Document the pattern for external API integrations 4. Add integration test verifying idempotency on retry ## Acceptance Criteria - [ ] HTTP requests include deterministic Idempotency-Key header by default - [ ] Key derivation is documented - [ ] Integration test covers crash-recovery scenario - [ ] Email tool also implements idempotency pattern ## Tags: atomicity, reliability, http, side-effects