Fix workflow library unsupported badge

[JPPhoto]

Summary

Fixes Workflow Library callability messaging after Call Saved Workflow support landed. The prior work created too much output noise in the Workflow Library by surfacing negative sub-workflow compatibility state on ordinary workflows. This PR removes that negative badge from the general library view and adds a positive Callable badge only when a workflow can be called by another workflow (i.e. it has a Workflow Return node).

Fixed callable workflow graph validation so saved optional inputs without explicit values use invocation defaults instead of being coerced to None.

Also fixed call-saved-workflow dynamic inputs to automatically resync when a selected child workflow's exposed fields change, preventing stale caller workflows from showing missing-field errors.

Related Issues / Discussions

QA Instructions

• Open the Workflow Library.
• Confirm ordinary workflows without a Workflow Return node do not show Unsupported.
• Confirm workflows that can be used by Call Saved Workflow show a Callable badge.
• Confirm the Call Saved Workflow node picker still disables non-callable workflows and displays the detailed reason there.

Merge Plan

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Tests added / updated (if applicable)
• ❗Changes to a redux slice have a corresponding migration
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)

[Pfannkuchensack]

Findings

1. Medium - board value "none" is not normalized, breaking callability of workflows that explicitly set "no board"

• Path/line: invokeai/app/services/shared/workflow_graph_builder.py:309
• Evidence chain (reproduced):
  1. The board picker persists three sentinels for a WithBoard input: "auto", "none", or a {board_id} object (invokeai/frontend/web/src/features/nodes/components/flow/nodes/Invocation/fields/inputs/BoardFieldInputComponent.tsx:32-40, invokeai/frontend/web/src/features/nodes/types/field.ts:609). Both "auto" and "none" mean "no board" in a server-side call context (see getBoardField in invokeai/frontend/web/src/features/nodes/util/graph/buildNodesGraph.ts:27-39).
  2. Commit 49cb00bb75 added normalization for exactly one of the two sentinels: at invokeai/app/services/shared/workflow_graph_builder.py:309 it omits the field only when field_name == "board" and value == "auto". For value == "none" it falls through to graph_node["board"] = "none" (a bare string).
  3. invokeai/app/services/shared/workflow_graph_builder.py:364 runs Graph.model_validate(...). board is typed Optional[BoardField] (invokeai/app/invocations/fields.py:500, BoardField at :244), so the string "none" fails validation.
  4. Reproduced: building a graph from a workflow whose blank_image node has board: "none" raises pydantic ValidationError: nodes.image-1.blank_image.board Input should be a valid dictionary or instance of BoardField [input_value='none']. The sibling "auto" test passes; all 7 existing tests/app/services/test_workflow_graph_builder.py pass.
• Consequence (two triggers):
  • Compatibility/badge: the library list endpoint computes get_workflow_call_compatibility per item (invokeai/app/api/routers/workflows.py:212-223), which runs build_child_workflow_sessions -> build_graph_from_workflow (invokeai/app/services/session_processor/workflow_call_batch.py:629,697). The ValidationError (a ValueError subclass) is caught at invokeai/app/services/shared/workflow_call_compatibility.py:213, yielding is_callable=False, reason=InvalidGraph. So a workflow that is otherwise perfectly callable but whose image node is set to "None (Uncategorized)" never gets the new "Callable" badge (invokeai/frontend/web/src/features/workflowLibrary/util/workflowLibraryListItemState.ts:18).
  • Runtime: an actual Call Saved Workflow to such a workflow fails at graph build with the same ValidationError.
  • Net effect: choosing the default board ("Auto") makes a workflow callable; choosing the first-class "None" option silently makes it uncallable with an opaque graph-validation reason. This asymmetry is introduced by the same commit that added board normalization.
• Missing test: To expose this issue, add a test that builds a graph from a workflow whose WithBoard node has board value "none" and asserts the resulting node's board is None (mirror test_build_graph_from_workflow_uses_default_for_legacy_auto_board_values in tests/app/services/test_workflow_graph_builder.py; also add a compatibility test asserting such a workflow is reported is_callable=True).

2. Low - dead unsupported-badge code path and now-unused compatibility helper after the badge rewrite

• Path/line: invokeai/frontend/web/src/features/workflowLibrary/util/workflowLibraryListItemState.ts:15-18
• Why: getWorkflowLibraryListItemState now hardcodes showUnsupportedBadge: false and unsupportedMessageKey: null. As a result the entire unsupported-badge branch in invokeai/frontend/web/src/features/nodes/components/sidePanel/workflow/WorkflowLibrary/WorkflowListItem.tsx:148-167 (Tooltip + t('nodes.savedWorkflowUnsupported'), t('workflows.savedWorkflowUnsupportedDescription')) is unreachable, and getWorkflowCallCompatibilityState / WorkflowCallCompatibilityMessageKey in invokeai/frontend/web/src/features/workflowLibrary/util/workflowCallCompatibility.ts become unused exports.
• Scenario: not a runtime defect; the removal of the "unsupported" badge appears intentional (commit bc3902885a), but the dead JSX branch, the retained field on the state type, and the orphaned helper/i18n strings are incomplete cleanup that will confuse future readers.
• Note: no test can meaningfully cover "code that never runs"; recommend deleting the dead branch/exports or restoring intended behavior. Verify with the repo's pnpm lint:knip (out of scope for this review).

[JPPhoto]

@Pfannkuchensack Thanks!

Finding 1 applies. I added failing backend tests for board: "none" in graph building and workflow-call compatibility, then fixed workflow_graph_builder.py to normalize both "auto" and "none" board sentinels to the default None behavior.

Finding 2 partially applies. The dead Workflow Library unsupported-badge state/JSX and unused locale description were removed, but the compatibility helper itself was not removed because it is still used by the Call Saved Workflow node picker.

I wonder if the node dropdown should only show callable workflows or if showing everything is a signal that something may not be callable that the user expects to be. My concern is that querying all workflows might be burdensome. I went ahead and implemented that.

[Pfannkuchensack]

Really good Feature.