fix: reject change requests for dealless orders

[garvitkaushik-123]

Summary

• normalize omitted order deal IDs to an empty string instead of persisting null
• reject change requests for orders without a deal reference using a structured HTTP 400 response
• guard legacy records where deal_id is already null before constructing the change-request model

Why

Orders created without a deal ID are valid through the public orders endpoint, but requesting a change against one passed null into the ChangeRequest model and raised an uncaught validation error. That surfaced as an unstructured HTTP 500.

The write-side normalization prevents new null records, while the read-side check protects records already stored with the old shape.

Testing

• verifies new dealless orders persist an empty deal ID
• verifies a legacy order with a null deal ID returns deal_id_required with HTTP 400
• verifies the rejected request does not create a change-request record
• full suite: 1,480 passed, 28 skipped
• changed-file lint, formatting, and whitespace checks pass

Closes #61

[Sirajmx]

Confirmed the fix, and it's correct on its own — verified test_existing_order_with_null_deal_id_returns_structured_error
passes in isolation. But there's a real interaction with #64 worth flagging before this merges,
since the two of you opened within 10 minutes of each other and neither could have seen the
other's change.

#64 makes idempotency_key a required field on POST /api/v1/change-requests. Your new test's
payload doesn't include one:

json={
    "order_id": "ORD-TEST001",
    "change_type": "impressions",
    "reason": "Increase campaign reach",
},

Once #64 is in, that request gets rejected at validation (422) before it ever reaches the
deal_id_required check this test exists to verify — so the test fails on 422 vs the expected
400. Confirmed this locally, deterministically, merging both onto a common base.

Direction: add "idempotency_key": "idem-null-deal-1" (or any non-empty string) to that one
payload. That's the only call this PR makes to that endpoint, so it's the only place this bites.
Verified the one-line fix locally — full suite green (1498 passed, 0 failed) with both PRs and
#63 combined. Happy to merge right after #64 once this is in; no reason to block on ordering
otherwise.