Add a flag/variable to indicate whether a workflow run is part of a bulk execution

### 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] 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] Please do not modify this template :) and fill in all the required fields.

### 1. Is this request related to a challenge you're experiencing? Tell me about your story.

I was trying to use the workflow's bulk execution feature to process multiple inputs at once, and I ran into a problem when the workflow calls an external API that has strict rate limits.

When running a single input, there's no issue. But when the same workflow is triggered via bulk execution, many runs fire in a short period of time and hit the API's rate limit. To handle this properly, I want to add logic inside the workflow itself — such as throttling requests or inserting a wait/delay — but only when the run is actually part of a bulk execution.

The problem is that, from inside the workflow, there is currently no way to determine whether the current run was triggered as part of a bulk execution or as a single, individual execution. Without this information, I can't conditionally branch the workflow logic (e.g., "if this is a bulk run, wait N seconds before calling the API").

### 2. Additional context or comments

As a workaround, it's technically possible to avoid using the bulk execution feature altogether and instead design the workflow to accept either a single file input or a batch-style input (e.g., a list) manually, then handle rate limiting inside the workflow logic myself.

However, it would be much more convenient if Dify's bulk execution feature natively exposed some kind of system variable or flag (e.g., something like sys.is_bulk_execution or similar) that workflow nodes could reference directly. This would let workflow authors add appropriate throttling/wait logic without having to redesign their input handling just to detect bulk vs. single execution.

This would be especially useful for workflows that call external APIs with rate limits, since bulk execution can easily trigger many concurrent/rapid calls.

### 3. Can you help us with this feature?

- [ ] I am interested in contributing to this feature.

The issue names no files, tests, or entry points. Start by locating the workflow bulk-execution path and the system-variable exposure path; done means a workflow can distinguish bulk from single runs and use that value for conditional throttling.

Written by the indexing model from the issue text.