Workspaces opening specified window occurrences, not just apps

### Description of the new feature / enhancement

The current capture system only records application-level identity (e.g., “Microsoft Word”), so restoring a captured state can only reopen the app—not the specific document, tab, or file that was active at the time.
A deeper metadata system would capture contextual identifiers for each window, allowing the system to reopen the exact resource when possible.
What “tracking” means in this context
Tracking refers to capturing structured metadata about each window when it is saved. This metadata goes beyond the window title and includes:
- Document paths (Word, Excel, Notepad, PDF readers)
- Browser tab URLs (Chrome, Edge, Firefox)
- File Explorer folder paths
- Application-specific identifiers (e.g., VS Code workspace, Photoshop file)
- Tab identifiers for tabbed applications
- Window role (main window, child window, dialog)
This metadata is stored alongside the window snapshot and used during restoration.

When restoring a captured layout:
- If the resource still exists
- Open the exact document, tab, or folder.
- Restore the window to its saved position and size.
- If the resource no longer exists
- Open the application’s main window instead.
- Optionally show a notification that the resource was missing.
- If the application supports multiple windows
- Open each captured resource in its own window.
- Avoid collapsing everything into a single instance.
This ensures the restored layout matches the user’s original working state as closely as possible.

Metadata examples by application type
Word / Excel / Office apps
- File path
- Document title
Browsers
- URL
- Tab title
- Container/profile (Firefox)
- Workspace (Edge vertical tabs, Chrome tab groups)
File Explorer
- Folder path
- Pane state (details, preview, navigation)
- Active tab (Windows 11 tabbed Explorer)
Tabbed applications
- Active tab index
- Tab title
- Tab resource (file path, URL, project name)
Multi-window apps (Photoshop, VS Code, Notion)
- Workspace or project path
- Active file
- Panel layout (if available)

Why this feature matters
This deeper metadata system turns window capture into true session restoration, not just app launching. It supports:
- Multi-document workflows
- Research sessions with many browser tabs
- Project-based work across multiple apps
- Complex layouts that need to be restored exactly
It also reduces friction when switching between tasks or workspaces.

This would work better if it also supported multiple resolutions for multiple monitors, as several others have noted this one doesn't.

### Scenario when this would be used?

Example usage scenarios
1. Restoring multiple Word documents
Before:
You capture a layout with three Word windows open:
- C:\Docs\Report.docx
- C:\Docs\Budget.xlsx
- C:\Docs\Notes.docx
After:
When restoring:
- If all three files exist → all three open in separate windows.
- If one file is missing → Word opens its main screen for that one window.
This avoids the current behavior where only a single Word instance opens.

2. Restoring browser tabs
Before:
You capture a layout with:
- Chrome window with 5 tabs
- Edge window with 3 tabs
- Firefox window with 2 tabs
After:
Restoration reopens:
- The same browsers
- The same windows
- The same tabs
- In the same order
- With the same active tab selected
If a URL is no longer reachable, the browser still opens the tab and shows its error page.

3. Restoring File Explorer
Before:
You capture:
- A File Explorer window on C:\Projects
- Another on D:\Media\Photos
After:
Restoration opens both windows at the correct folders.
If a drive is missing, Explorer opens “This PC” instead.

4. Restoring a mixed workflow
Before:
You capture a layout with:
- Word document
- Excel spreadsheet
- Chrome with 4 tabs
- File Explorer
- VS Code workspace
- Adobe Acrobat PDF
After:
Restoration reopens:
- The same documents
- The same tabs
- The same folders
- The same workspace
- The same PDF
- All in the same positions and sizes
Missing files fall back to the app’s main window.

### Supporting information

_No response_

No files, tests, or entry points are identified in the issue, so begin by locating the capture and restoration components for window state. Done would require a defined, implementable scope for resource metadata, per-window restoration, missing-resource fallbacks, and multi-monitor behavior.

Written by the indexing model from the issue text.