fix(frontend): keep workspace settings on the workspace in the URL

[fmaass]

Problem

Opening one workspace's settings and then navigating to another workspace's settings leaves the page showing the first workspace. MainApp renders a single WorkspaceSettings instance for every /workspaces/:id/settings/* view, but the component loaded its workspace only in onMount. After such a switch the form still holds the previous workspace's name, key, description and — on the Danger tab — its "Active Workspace" toggle and delete confirmation, while saveWorkspace() and deleteWorkspace() already address the new id from the URL: saving writes one workspace's settings onto another, and the delete confirmation is validated against the old workspace's name while deleting the new one.

Fix

• The workspace load now follows the workspaceId prop (the same $effect + load-key pattern WorkspaceWelcome uses), with a load-version guard so a superseded response cannot repopulate the form.
• Workspace, form, and delete-confirmation state are cleared on every switch, so an unloadable workspace falls through to the existing "Workspace not found" state instead of silently showing a different workspace.
• MainApp clears stale currentWorkspace context as soon as the route changes, then hydrates it from the routed workspace response.
• Save and delete completions are fenced the same way: both pin their target workspace before awaiting, so what the server actually changed is still applied to the workspace list wherever the user has moved to, while view-scoped effects only run while that workspace is still on screen.
• The delayed post-delete redirect rechecks the active route and is cancelled when the component is destroyed.

Verification

• Manual: open workspace A's settings, then navigate in-app to workspace B's settings. Before: the form still shows A. After: the form, the Danger tab and the sidebar identity all follow the URL. With a throttled network, a superseded response for A can no longer overwrite B's form, and an in-flight delete of A no longer redirects away from B.
• npm run check, npm run typecheck, and npm run build pass.
• The overlaid frontend test suite passes with regression coverage in test: begin API v2 fixture and contract migration core-tests#1.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[fmaass]

I have read the CLA Document and I hereby sign the CLA

[fmaass]

recheck

[fmaass]

Heads-up for maintainers: the failing cla check appears to be on the workflow side rather than the signature — the run errors with Branch cla-signatures not found before it can record anything (see run 31310298157). cla.yml points path-to-signatures at branch: cla-signatures, which does not exist in this repo yet, so I suspect every external contributor will hit the same failure. My sign-comment is posted above; once the branch exists, a recheck should record it and flip the check.

[stefan-ernst]

Thank you for the contribution @fmaass - I will have a look at this PR + the cla issue

[stefan-ernst]

recheck

[stefan-ernst]

ok now I signed the cla but it does not matter :)
thanks again for the contribution, merging now