[Fix-18448][UI] Guard missing workflow definition in DAG menu

[yongster]

Was this PR generated or assisted by AI?

YES. AI assisted with code exploration, the null-safety changes, and validation.

Purpose of the pull request

Fixes #18448. Prevent the DAG from receiving an invalid response that lacks workflowDefinition.

Brief change log

• Validate the workflow-definition response before mounting the definition DAG.
• Validate the instance dagData response before mounting the instance DAG.
• Clear invalid state and show the existing request-failed message instead of passing a partial object to DAG consumers.
• Retain defensive optional chaining for the DAG menu visibility checks.

Verify this pull request

• Ran pnpm exec eslint for the changed DAG and detail-page files.
• Ran pnpm run build:prod (vue-tsc --noEmit and production Vite build).
• The UI package has no configured unit-test runner or existing component-test setup; no non-executable test files were added.

Pull Request Notice

Pull Request Notice

[SbloodyS]

Guard the missing definition at the data boundary, not only in two menu conditions

The linked issue assumes that props.definition exists while props.definition.workflowDefinition is undefined. The two optional-chain changes prevent the releaseState reads from failing, but the same payload still crashes elsewhere in the DAG path:

• workflow/definition/detail/index.tsx:64-67 reads res.workflowDefinition.releaseState and .locations.
• workflow/instance/detail/index.tsx:61 reads res.dagData.workflowDefinition.locations.
• use-custom-cell-builder.ts:122 reads definition.workflowDefinition.locations while building the graph.
• dag/index.tsx:374-430 mounts VersionModal and StartModal based only on the outer definition, then passes the missing inner object to them.

Therefore, the page may fail before the context-menu computed properties are evaluated, or fail later through another consumer. This patch suppresses one symptom but does not make the stated missing-workflowDefinition state safe.

Please add a regression test using the actual failing API payload, then either reject/handle the invalid response before rendering the DAG or consistently guard every consumer that supports this state. If workflowDefinition is contractually required, the correct fix is at the response/state boundary rather than adding isolated optional chaining.