Define Windows network workspace authorization in Desktop

**What problem would this solve?**
Desktop accepts workspace and directory paths through several renderer-to-main workflows, including starting a chat, running Git queries, maintaining recent directories, and supplying file-picker defaults. On Windows, UNC and device paths can cause native filesystem, Git, or process operations to contact a network location before Desktop has established that the user explicitly selected and authorized it. We need one product decision for whether network workspaces are supported and one authorization model that every workflow can apply consistently.

**What would a good outcome look like?**
Document which Windows path types Desktop supports. If network workspaces are supported, establish a main-process grant only through an explicit user action, bind it to the regular window/session that owns the workspace, and require that grant before any stat, Git, recent-directory, or backend-start operation. If they are not supported, reject UNC and device paths before the first native filesystem or process call. Define how persisted recent directories and picker defaults regain authorization in later sessions.

The verification plan should cover: an ungranted UNC path for each affected workflow; a normal local workspace; an explicitly granted network workspace if supported; stale grants after a window closes or changes workspace; and Windows device-path variants.

**Possible approaches**
- Reject all UNC/device paths in the main process.
- Permit network paths only when returned by the native picker, with sender-scoped in-memory grants.
- Persist narrowly scoped grants with an explicit reconnect prompt.
- Centralize validation and grant checks so chat startup, Git, recent directories, and picker defaults cannot drift.

The unused generic directory-creation bridge can be removed independently instead of broadening this design.

**Additional context**
This is a design decision and should not be implemented piecemeal until the supported network-workspace behavior and grant lifetime are agreed.

- [x] I have verified this does not duplicate an existing feature request

Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).

The issue describes a design problem for Windows network workspace authorization in the Desktop application. Start by examining the main process code handling workspace and directory paths, particularly for UNC and device paths. Look at the renderer-to-main workflows mentioned: starting a chat, running Git queries, maintaining recent directories, and file-picker defaults. The goal is to define a consistent authorization model, not to implement it yet. 'Done' means a documented decision on supported path types and a grant model.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.