[server] dispatch all statuses in batched webhooks

[xuu33030]

Summary

Fixes message status webhook batching so every status in a single change is dispatched instead of silently dropping all but the first.

• Constructs one MessageStatus per item in value["statuses"]
• Matches each status to its contact by wa_id or user_id
• Preserves sync and async handler behavior
• Prevents an already-completed listener from consuming later statuses in the same batch

Type of change

• Bug fix
• New feature
• Documentation update
• Refactor
• Chore / CI

Checklist

• I have read the contribution guidelines in CONTRIBUTING.md.
• The PR has a descriptive title and summary.
• I have added/updated tests where appropriate.
• I have run the test suite locally and all tests pass.
• I have updated documentation where required.
• I have added an entry to CHANGELOG.md if this change should be recorded.

How has this been tested?

• uv run pytest -q — 560 passed
• uv run ruff check .
• uv run ruff format --check .
• uv run ty check
• Direct webhook smoke test confirmed three statuses dispatch once with their matching contacts

The regression tests cover both synchronous and asynchronous clients, deliberately reverse the contact order to prove ID-based matching, and verify completed listeners ignore later updates in the same batch.

Breaking changes

None.

Related issues / PRs

Fixes #229.

Reviewer notes

This intentionally handles only multiple statuses within one change, matching the verified Meta batching behavior discussed in the issue. It does not add support for synthetic multiple-entry or multiple-change payloads.

[yehuda-lev]

Please read this before making changes
#229 (comment)

[xuu33030]

Thanks — I read that discussion before scoping the change. This PR intentionally handles only multiple statuses within a single change, which matches the verified Meta batching behavior. It does not add support for synthetic multiple-entry or multiple-change payloads.

[yehuda-lev]

@xuu33030 I'm talking about the question;

Do you have a real example of Meta sending multiple entry or multiple changes objects in one POST for message statuses? If so we'd like to see the raw payload (redacted as needed) — that changes the shape of the fix considerably (iterating entries and changes, not just statuses).

[xuu33030]

Sorry, I misunderstood your question. I do not have a real Meta payload showing multiple entry or changes objects in one message-status POST. Those cases in the issue were synthetic fixture variants, not observed webhook traffic. This PR only handles multiple statuses within a single change.