fix: enforce idempotency for change requests

[garvitkaushik-123]

Summary

• require a non-empty idempotency key on change-request creation
• replay the original change request for identical requests scoped to the same order
• return the shared idempotency conflict response when a key is reused with a different payload
• expire idempotency records after 24 hours, matching the other FD-12 endpoints

Why

POST /api/v1/change-requests was the only FD-12 money-mutating surface without replay protection. A client retry could create a second change request and place a duplicate material change into the approval queue.

The implementation follows the existing quotes/deals router pattern while preserving the current change-request payload fields. The namespace is scoped by order because this route permits optional authentication.

Testing

• added coverage for missing keys, identical replay, changed-payload conflicts, per-order scoping, and the 24-hour TTL
• updated existing change-request lifecycle tests for the required field
• full suite: 1,484 passed, 28 skipped
• changed-file lint, formatting, and whitespace checks pass

Closes #62

[Sirajmx]

Confirmed, and the underlying fix here is solid - reviewed it against #62's replay/duplication
scenario and it holds. But the hygiene gate is genuinely red right now
(hygiene / secret scan (gitleaks, changed range)), so this can't merge as-is.

Ran gitleaks 8.24.3 locally, unredacted, against the same range CI checks
(e5b367d..2c2633d). It's a false positive, not a real leak:

Finding:  "idempotency_key": "idem-apply-unapproved-1"
RuleID:   generic-api-key    Entropy: 3.708132
File:     tests/unit/test_change_request.py:601

idem-apply-unapproved-1 is a plain test fixture in test_cannot_apply_unapproved - same
pattern as idem-minor-1, idem-material-1, etc. elsewhere in this file. It just has enough
entropy in the longer name to trip gitleaks' generic-api-key rule where the shorter ones don't.

Direction: add an inline # gitleaks:allow comment on that line. One thing worth knowing before
you push it — gitleaks scans each commit in the range individually, not a squashed diff, so
adding a new commit on top won't clear the gate; the original commit still carries the
flagged line in history. Amend the existing commit (git commit --amend) and force-push,
rather than stacking a fix commit. Verified locally both ways: a stacked commit still shows
leaks found: 1 over the full range; amending clears it to no leaks found.

[garvitkaushik-123]

Gitleaks false positive fixed (inline allow comment, commit amended and force-pushed). All checks are green now, including the secret scan.

This is ready to merge but needs a formal approving review. @Sirajmx, could you approve when you get a chance?

[Sirajmx]

Verified: 1,463 unit + 39 integration tests passed (0 failed, matching CI exactly). Live E2E also passed - identical replays return the same record, while reusing a key with a different body correctly returns 409. Merging.