feat(frontend): dynamically disable file-dependent actions in the node picker

[LukasHirt]

Backend investigation

Read backend/pkg/executor/executor.go end-to-end plus the callers of Executor.Run (backend/pkg/service/workflows.go, backend/pkg/scheduler/scheduler.go, backend/pkg/sse/manager.go):

• vars["file.name"]/vars["file.content"] are only populated when resourcePath != "" at the top of Run() (executor.go:66-76). If GetContent fails or resourcePath is empty, those vars are simply never set — no error, no fallback.
• runAction's tag/comment/move/copy/rename branches all require a non-empty currentPath (seeded from resourcePath) and return a hard runtime error ("...action needs both a target file and...") when it's empty. notify is the only action that doesn't touch currentPath at all.
• Whether resourcePath is non-empty depends entirely on who calls Run, not on the graph itself:
  • scheduler.go:147 — s.executor.Run(ctx, authHeader, *wf, "schedule", "") — always an empty string. A Schedule Trigger can never provide a file. This is structurally impossible, not just unlikely.
  • service/workflows.go Run handler (manual "Run now") — resourcePath comes from an optional free-text field in ExecutionsPanel.vue ("File to run against (WebDAV path)"). It can work — Manual Trigger + file action is a legitimate, common workflow shape — but nothing in the graph guarantees the user filled it in.
  • sse/manager.go:306 — passes the real path from the file event that fired. The File Event Trigger is the only trigger that reliably supplies a file on every run.

Decision (evolved across this PR)

1. Started with a non-blocking warning in NodeDetailsPanel.vue.
2. Replaced/supplemented that with pick-time restriction in NodePicker.vue: disable file-dependent action entries when the picker's source node's upstream trigger doesn't reliably provide a file.
3. CI caught a real bug in step 2: build-workflow.spec.ts and run-workflow.spec.ts both build a Manual Trigger -> LLM -> Add Tag chain, and the picker was disabling "Add Tag" because the disable-check treated Manual Trigger the same as Schedule Trigger. That's too strict — Manual Trigger is only conditionally file-less (depends on what the user types into "Run now"), whereas Schedule Trigger is structurally file-less (the scheduler always calls Run with an empty resourcePath, full stop). Fixed by splitting the check in two:
   • hasUpstreamFileSource() keeps its original, stricter "only Event Trigger is reliable" semantics — still used for the informational NodeDetailsPanel nudge (fires for both Manual and Schedule).
   • canUpstreamProvideFile() is new and looser — only Schedule Trigger fails it — and is what NodePicker.vue now uses to decide what to hard-disable. Manual Trigger no longer blocks file-dependent actions in the picker.

What changed

• frontend/src/utils/flowValidation.ts (new): pure, tested graph-walk.
  • hasUpstreamFileSource(nodeId, nodes, edges) — true only if the upstream trigger is event (or none is reachable at all). Used by NodeDetailsPanel's warning.
  • canUpstreamProvideFile(nodeId, nodes, edges) — true unless the upstream trigger is schedule (the only structurally-impossible case). Used by NodePicker's hard-disable.
  • isFileDependentActionType(actionType) — tag/comment/move/copy/rename are file-dependent; notify is not.
• frontend/src/components/NodePicker.vue: new sourceNodeId/nodes/edges props. Disables file-dependent entries (grayed out, inline reason + tooltip, click no-ops) only when the source's upstream trigger is a Schedule Trigger.
• frontend/src/components/NodeDetailsPanel.vue: shows a non-blocking warning banner for file-dependent actions whose upstream trigger isn't an Event Trigger (Manual or Schedule) — kept as a secondary safety net, since Vue Flow lets users rewire an action node's incoming edge by dragging directly between existing nodes (bypassing the picker), and workflows created via the REST API never go through the picker at all.
• frontend/src/views/WorkflowBuilder.vue: threads pickerConnectFrom/nodes/edges into NodePicker, and nodes/edges into NodeDetailsPanel.

Left the node picker's categorization, the "+" button, node positioning, config-modal OK-button/auto-open, and output hints untouched — those are owned by other in-flight changes.

Test plan

TDD throughout, including for the CI-driven follow-up fix (tests updated/added first, confirmed failing against the pre-fix code, then implementation, then confirmed passing):

• frontend/tests/unit/flowValidation.spec.ts (14 cases): hasUpstreamFileSource covers direct manual→move flags, direct event→move doesn't, manual→llm→move still flags, event→llm→move doesn't, schedule-trigger case, orphan-node case. canUpstreamProvideFile covers the same shapes but asserts Manual Trigger is not flagged and only Schedule Trigger is.

• frontend/tests/unit/NodePicker.spec.ts (5 cases): Move File not disabled for a manual-trigger source; disabled (with reason text) for a schedule-trigger source; not disabled for an event-trigger source; clicking a disabled entry doesn't emit select; non-file action (Send Notification) stays enabled regardless of source.

• frontend/tests/unit/NodeDetailsPanel.spec.ts (3 cases): warns for manual→move, doesn't warn for event→move, doesn't warn for notify.

• npm run test:unit — 5 test files, 26 tests, all passing

• npm run check:types — clean

• npm run lint — clean

• CI (gh pr checks 22) re-run after the fix — see checks on this PR