Workflows marked removed/manual persist in UI after restart; no supported hard-delete or purge path Body

## Summary

Workflows that were intentionally disabled/removed still persist in the GitHub Copilot app UI after restart, and there does not appear to be a supported way to permanently delete them.

This seems like both:
1. a bug in workflow persistence / UI state, and
2. a product gap because there is no true delete/purge action.

Related issue: #1045

## Expected behavior

After workflows are disabled/removed, I would expect one of these to be true:

1. They disappear from the app UI, or
2. The app clearly indicates they are archived/disabled and provides a supported hard-delete/purge option.

## Actual behavior

The workflows remain visible in the app even after all of the following:

- setting every workflow to `manual`
- renaming them with a `[REMOVED ...]` prefix
- restarting the app
- resetting local app/WebView state by renaming:
- `Local Storage`
- `Session Storage`
- `Preferences`
- `Secure Preferences`

After reopening the app, the workflows still reappear.

## Lifecycle gap

The app/tooling supports workflow creation and modification, but there does not appear to be an equivalent supported remove/delete operation.

In practice, this means workflows can be:
- created easily
- edited easily
- disabled manually

But they cannot be fully removed from the UI/state in a supported way.

That makes the workflow lifecycle incomplete and leaves users with persistent records they can no longer clean up properly.

## Why this seems like a bug

This suggests the workflow list is being rehydrated from another source of truth, but the app does not expose that behavior clearly and does not provide a supported way to fully remove workflow records.

From the user perspective, the workflows appear "stuck":
- they are no longer intended to run
- they were explicitly set to manual
- local cache/state was reset
- but they still persist in the UI

## Impact

- cluttered workflow/automation UI
- confusion about whether workflows are actually gone
- concern that old automations may still affect app performance or state
- no practical cleanup path after creating many experimental workflows

## Requested fix

Please add one or both of these:

1. A true workflow delete/purge action
2. Clearer UX that distinguishes:
- active workflows
- manual/disabled workflows
- archived workflows
- deleted workflows

If hard delete is intentionally unsupported, the app should say so explicitly and explain what "removed" actually means.

## Environment

- OS: Windows
- App: GitHub Copilot app
- Context: large number of workflows created for experimentation/testing

## Additional notes

I was able to neutralize the workflows operationally by setting them all to `manual`, but I was not able to make them disappear from the UI.

This makes it hard to tell whether they are truly inactive versus just visually lingering.