bug(api): completion-conversations end-time filter uses strict `<` instead of `<=`, silently dropping boundary conversations

### Self Checks

- [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542).
- [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general).
- [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones.
- [x] I confirm that I am using English to submit this report, otherwise it will be closed.
- [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
- [x] Please do not modify this template :) and fill in all the required fields.

### Dify version

1.17.0 (main branch, commit `6bc7f01261`)

### Cloud or Self Hosted

Self Hosted (Docker)

### Steps to reproduce

1. In the Dify console, open any **Completion-type** app's conversation log page.
2. Set a date/time filter with an **end time**, e.g. `2024-01-15 14:30`.
3. Note which conversations are returned.
4. Compare results with a **Chat-type** app using the same end-time filter.

### ✔️ Expected Behavior

Both Completion and Chat conversation list endpoints should use an **inclusive** upper bound (`<=`) for the end-time filter. A conversation created at exactly `2024-01-15 14:30:59` (the last second of the specified end minute) should appear in the results.

### ❌ Actual Behavior

The **Completion** conversation endpoint (`GET /apps//completion-conversations`) uses a **strict less-than** (`<`) comparison for the end-time, which silently excludes conversations created at exactly the boundary second.
The **Chat** conversation endpoint (`GET /apps//chat-conversations`) correctly uses `<=`.
## Root Cause (Code Evidence)
Both endpoints call `parse_time_range()` which parses end time as `HH:MM` with `second=0`, then both immediately call `.replace(second=59)` — clearly intending to include the full minute up to `:59`. But the comparison operators then diverge:
**`CompletionConversationApi.get` — `api/controllers/console/app/conversation.py` line 141-143 (BUG):**
```python
if end_datetime_utc:
end_datetime_utc = end_datetime_utc.replace(second=59)
query = query.where(Conversation.created_at < end_datetime_utc) # ← strict <

Start in api/controllers/console/app/conversation.py at CompletionConversationApi.get, then compare its end-time handling with the Chat conversation endpoint. Verify that a conversation created at the final second of the selected minute is included by the completion-conversations filter, matching the documented expected behavior.

Written by the indexing model from the issue text.