Suite wizard's success result is never rendered — the dialog unmounts in the same tick it is set

[rubenvdlinde]

Summary

openspec/specs/suite-wizard/spec.md, scenario "Successful submission
creates the suite with its members", ends with:

AND the wizard MUST show a success result

That result is never rendered. It is not a race — it cannot be observed by
any user under any timing.

Mechanism

src/dialogs/SuiteWizardDialog.vue:172-180:

const created = await objectStore.saveObject('suite', payload)
if (this.$refs.wizard) {
    this.$refs.wizard.setResult({ success: true })   // enters the result phase
}
this.$emit('created', created?.id)                   // ...and immediately:

src/views/suites/SuitesIndexView.vue:93-98:

onSuiteCreated(suiteId) {
    this.showWizard = false                          // unmounts the dialog
    if (suiteId) { this.$router.push({ name: 'SuiteDetail', ... }) }
}

CnWizardDialog is rendered under v-if="show", so setting showWizard = false unmounts it. Both updates land in the same synchronous tick, before
Vue's next render flush — so the [data-testid-phase="result"] block and its
success-text ("Suite created.") are set and destroyed without ever being
committed to the DOM.

Evidence

The first version of the e2e test asserted the success banner. It waited the
full 30 s and failed with element(s) not found; the page snapshot captured at
failure contains no dialog in the DOM at all — not a dialog showing the
wrong phase.

Impact

Low severity, but it is a spec clause the implementation does not meet, and the
:success-text="t('softwarecatalog', 'Suite created.')" prop on
SuiteWizardDialog.vue:34 is dead configuration that reads as if it works.

Options

1. Have onSuiteCreated navigate but leave the dialog mounted until the user
   dismisses the result (matches the spec, costs an extra click).
2. Keep the navigate-away UX and drop the "MUST show a success result" clause
   from the spec, replacing it with the outcome that IS observable — landing on
   the new suite's detail page. Then also remove the dead success-text prop.

Option 2 looks closer to the intended UX, but it is a spec change and must
be decided by a maintainer, not by the agent writing the tests against it.

What the tests do meanwhile

tests/e2e/spec-coverage/suite-wizard.spec.ts covers the two THENs that hold
(the suite is created; applicaties contains both attached module ids) and
asserts the navigation instead of the banner. The partial coverage is
disclosed in a comment block in the test itself, so the green is not read as
proof of the whole scenario.