[Feature]: Configurable retention period for deleted worktrees

### Problem or use case

This has happened to me twice: I deleted worktrees after finishing work, then another agent session later needed documents or files from those worktrees. By then, the directories had already been permanently deleted.

The worktrees can be large, and there was no copy available in the Windows Recycle Bin to recover. Orca's current deletion path removes the files directly rather than sending them to the Recycle Bin, regardless of size. Recovering committed code alone does not recover local documents or other untracked or ignored files that another session may still need.

I would like a configurable recovery window so I can remove finished worktrees from the workspace without immediately losing files that another session subsequently discovers it needs.

In Orca 1.4.198 on Windows, local worktree deletion moves the directory into `.orca-worktree-trash/wt--`, removes its Git registration, and queues permanent deletion immediately. The empty `.orca-worktree-trash` directory can remain, but its contents are not retained for recovery. There is no retention setting in this deletion path.

### Proposed solution

Add an optional deleted-worktree retention setting, for example:

- Delete immediately (the current default).
- Keep for a selected number of hours or days, then delete automatically.

When retention is enabled, preserve the deleted worktree directory until its retention period expires, including across app restarts. Background cleanup should respect that expiry instead of immediately sweeping retained directories.

Show the selected retention behavior in the deletion confirmation so users know when files will be permanently removed. A way to view retained worktrees, recover their files, and empty the trash early would make the feature easier to use. Preserve enough metadata to identify the original repository, branch, path, and deletion time.

### Alternatives or additional context

Currently I have to keep the worktree active or make a separate backup before deleting it. A configurable retention period would let me clean up the workspace while keeping a short recovery window. Retention uses disk space, so keeping immediate deletion as the default would preserve existing behavior.

This is a request for intentional, time-limited retention, separate from failed cleanup such as #16958. File recovery and restoring a deleted Git branch should be distinguished clearly in the UI.

Start by tracing the existing worktree deletion path and background cleanup described in the issue. Then inspect the deletion confirmation and retained-directory metadata behavior; done means configurable immediate or time-limited retention survives restarts, expiry cleanup works, and the UI communicates deletion timing without changing the default.

Written by the indexing model from the issue text.