File upload count limit can be bypassed by pasted files in chat input

### Self Checks

- [x] I have read the Contributing Guide and Language Policy.
- [x] This is only for bug report, if you would like to ask a question, please head to Discussions.
- [x] I have searched for existing issues, including closed ones.
- [x] I confirm that I am using English to submit this report, otherwise it will be closed.
- [x] Please do not modify this template :) and fill in all the required fields.

### Dify version

1.14.0, and the same upload path still appears on current `main`.

### Cloud or Self Hosted

Self Hosted

### Steps to reproduce

1. Create a chatflow/chat app.
2. Enable **File Upload** in the app features.
3. Set the maximum upload count to `3`.
4. Open the chat input / preview panel.
5. Instead of using the official upload button, paste image files directly into the chat input with `Ctrl+V` / `Cmd+V` multiple times, or paste multiple files from the clipboard.
6. More than 3 files can be added to the message.
7. Send the message.

### ✔️ Expected Behavior

All file input methods should respect the configured maximum upload count.

When `number_limits` is set to `3`, users should not be able to add or send more than 3 files, regardless of whether the files are added via:

- the upload button
- clipboard paste
- drag-and-drop
- remote file URL

The UI should either ignore extra files or show a clear error message.

### ❌ Actual Behavior

The upload button respects `number_limits`, but clipboard paste does not.

Users can paste more than the configured maximum number of files into the chat input. The message can then be sent with too many files. In my local reproduction, the assistant/workflow does not respond normally after sending the message with the exceeded file count.

### Root cause analysis

The upload button path checks `fileConfig.number_limits` before calling `handleLocalFileUpload`:

https://github.com/langgenius/dify/blob/main/web/app/components/base/file-uploader/file-input.tsx#L18-L23

However, `handleClipboardPasteFile` calls `handleLocalFileUpload` directly:

https://github.com/langgenius/dify/blob/main/web/app/components/base/file-uploader/hooks.ts#L299-L306

`handleDropFile` also calls `handleLocalFileUpload` directly:

https://github.com/langgenius/dify/blob/main/web/app/components/base/file-uploader/hooks.ts#L326-L335

But the shared `handleLocalFileUpload` function itself does not check `fileConfig.number_limits`:

https://github.com/langgenius/dify/blob/main/web/app/components/base/file-uploader/hooks.ts#L239-L297

So the file count limit is enforced only in the upload button component, not in the shared upload logic.

### Related issues

This seems related to previous upload configuration bypass issues:

- #27200 fixed/covered clipboard paste when file upload is disabled.
- #28945 fixed/covered drag-and-drop when file upload is disabled.

This issue is similar, but about `number_limits`: pasted files can exceed the configured maximum upload count.

### Suggested fix

Move the file count validation into the shared upload hook so every upload entry point uses the same limit check.

Possible places to enforce it:

- `handleLocalFileUpload`
- `handleLoadFileFromLink`
- `handleClipboardPasteFile`, especially for multiple pasted files
- `handleDropFile`, especially for multiple dropped files

It would also be safer to block sending if the current file list already exceeds `fileConfig.number_limits`.

I can submit a PR for this if the proposed direction sounds acceptable.