fix(api): use f-string for raise messages in trigger debug event selectors

### 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.15.0

### Cloud or Self Hosted

Self Hosted (Docker)

### Steps to reproduce

1. Open a workflow app with a trigger start node
2. Go to Draft > Trigger > Run single node debugging
3. Pass an invalid or nonexistent node_id in the API call
4. Observe the error message returned in the response/logs

### ✔️ Expected Behavior

Error message should read clearly, e.g.:
Node data not found for node abc-123

### ❌ Actual Behavior

Error message renders as a Python tuple instead of a formatted string:
("Node data not found for node %s", "abc-123")

This is the same bug pattern fixed yesterday in #37607 for
resume_workflow_execution — raise ValueError("...%s...", var) passes
multiple positional args to Exception.__init__ instead of interpolating
the string.

While reading through the trigger debug code after that fix merged, I
noticed 4 more instances of this exact pattern that weren't covered:
- api/core/trigger/debug/event_selectors.py (3 instances)
- api/controllers/console/app/workflow.py (1 instance)

The fix is mechanical — swap to f-strings. Happy to submit a PR with
the fix if this looks right.

Start by inspecting the four raise sites in api/core/trigger/debug/event_selectors.py and api/controllers/console/app/workflow.py, then reproduce the invalid node_id request described in the issue. Replace the tuple-producing messages with formatted error strings and verify the response or logs show the node ID in readable text.

Written by the indexing model from the issue text.