Fetching the threads for a commitfest right now is one GET /api/v1/patches/<id>/threads, which makes fetching the history thousands of requests.

MailThread is already joined to Patch, so we can fetch them all with just one additional SQL query. I gated this behind a query parameter, although it doesn't have to be.

I also exposed enterdate and leavedate. Like draft from #114, these fields are already stored and visible in the UI, they just weren't in the API yet.

In short: GET /api/v1/commitfests/<cfid>/patches now returns enterdate and leavedate on every entry, and each entry gains a threads list when called with ?include=threads:

{"id": 1, "name": "...", "status": "Ready for Committer", "authors": ["..."],
 "last_email_time": "2025-01-20T06:53:39+00:00",
 "enterdate": "2025-01-26T10:48:31.579000+00:00", "leavedate": null,
 "threads": [{"messageid": "...", "subject": "...", "latest_message_id": "...",
              "latest_message_time": "...", "has_attachment": false}]}

The threads entries are the same shape /api/v1/patches/<id>/threads already returns, in the same order.

Notes:

• Threads are opt-in behind ?include=.
• Query param parsing is forgiving: include will just ignore unknown keys instead of erroring.
• enterdate and leavedate are unconditional since they're single fields not a join. We could gate those too, but I don't think it's necessary.
• The thread dictionary is built in one common place for both ?include=thread and /patches/<id>/threads
• Wrote a test confirming this is +1 query, not N+1