`Workflow Save As` behaves like `Save a Copy` for saved workflows, leaving the original tab dirty

## What problem are you experiencing?

`Workflow Save As` does not behave like normal `Save As` in most desktop or document-based applications.

For a workflow that has already been saved once, choosing `Save As` creates a new copy under the new filename, opens that copy in a new tab, and leaves the original workflow tab open and still dirty. In practice this behaves more like `Save a Copy` than `Save As`.

This is confusing because:

- I just saved the current work under a new name, but the original tab still appears unsaved and will still prompt on close.
- It is easy to think the current document has been renamed/rebased onto the new filename when that did not happen.
- It increases the chance of saving the old tab over the old filename by mistake and losing work or overwriting the wrong file.

## When does this problem occur?

This happens when working on an already-saved workflow and using `File -> Save As` to branch it under a new filename.

Expected behavior for `Save As`:

- The currently open workflow should become the newly named file.
- The current tab should stay the active tab.
- The workflow should no longer be dirty immediately after the save completes.
- The old filename should remain on disk unchanged unless I explicitly save to it again later.

What currently happens instead:

- A second workflow tab is created for the new filename.
- The new tab becomes active.
- The original tab remains open in its previous dirty state.
- Closing the original tab can still trigger an unsaved-changes prompt even though I just used `Save As`.

This is especially confusing when iterating on a workflow version-by-version and expecting standard file behavior.

## How often do you encounter this problem?

Multiple times per day

## How much does this problem affect your workflow?

Causes moderate inconvenience

## Current workarounds

- Use `Save` when I can, even when I really want to branch to a new filename.
- Mentally treat `Save As` as `Save a Copy`.
- Manually close or ignore the original dirty tab after the new tab opens.

These workarounds are easy to get wrong and add friction every time I want to branch a workflow.

## Ideas for solutions (Optional)

Two reasonable directions:

1. Make `Save As` follow standard document semantics for both unsaved and already-saved workflows:
- save the current workflow state to the new filename
- update the current tab/document identity to the new path
- clear the dirty state after save

2. If the current behavior is desired, rename the command to something like `Save a Copy` or `Duplicate to New File`, and consider adding a separate true `Save As`.

The first option would better match user expectations.

## Additional context

The current implementation appears to already behave like standard `Save As` for unsaved temporary workflows, but not for already-saved workflows, which makes the inconsistency more noticeable.

┆Issue is synchronized with this [Notion page](https://www.notion.so/Issue-10253-Workflow-Save-As-behaves-like-Save-a-Copy-for-saved-workflows-leaving-the-origin-3276d73d3650814abd2ee3f43e0e45fd) by [Unito](https://www.unito.io)

Start at the frontend entry point for File → Save As and trace how the command handles already-saved workflows. Compare that path with the stated behavior for unsaved workflows, then verify that Save As keeps the current tab active, updates its filename, clears its dirty state, and leaves the old file unchanged.

Written by the indexing model from the issue text.