fix(desktop): repos dir setting is silently ignored on Windows

## Summary

The **Repos Directory** setting in workspace settings is silently ignored on Windows. The field accepts a path, validates nothing, saves successfully, and has no effect — `~/.buzz/REPOS` remains a plain in-nest directory. There is no error, no warning, and no platform note in the UI.

## Environment

- Buzz Desktop 0.5.11 (packaged OSS release), Windows 11

## Reproduction

1. Open workspace settings → **Repos Directory**.
2. Enter an existing absolute path (e.g. `C:\Users\you\Development`). Save.
3. Restart Buzz. Inspect `~/.buzz/REPOS`.

**Expected:** `REPOS` resolves to the configured directory, so agents work in existing local checkouts — as the field's own help text promises.
**Actual:** `~/.buzz/REPOS` is an ordinary empty directory. The setting is persisted but has no effect. No feedback of any kind.

## Root cause

`desktop/src-tauri/src/managed_agents/repos.rs:143`

```rust
#[cfg(not(unix))]
pub fn ensure_repos_symlink(nest_root: &Path, _repos_dir: Option<&str>) -> Result<(), String> {
let repos_path = nest_root.join("REPOS");
fs::create_dir_all(&repos_path).map_err(|e| format!("create {}: {e}", repos_path.display()))
}
```

The `repos_dir` parameter is underscore-prefixed and unused. The entire symlink implementation — plus `validate_repos_dir`, which would otherwise reject bad paths — is behind `#[cfg(unix)]` and compiled out.

Meanwhile the UI offers the field unconditionally, with no platform caveat. `desktop/src/features/communities/ui/EditCommunityDialog.tsx:203`

```tsx
Repos Directory
(optional)
```
```tsx
Point the agent's REPOS directory at an existing
folder so agents work in your local checkouts. Leave blank to use
the default location.
```

The value is expanded (`expandTilde`) and saved through `useCommunities.tsx` like any other setting, so from the user's side it looks like it worked.

## Impact

Windows users who point Repos Directory at their projects folder get agents cloning into `~/.buzz/REPOS` instead — a second copy, disconnected from their real checkouts, with no indication why.

## Suggested fix

Either would resolve the silent failure:

- **Implement it.** Windows supports directory symlinks (`std::os::windows::fs::symlink_dir`), though it needs Developer Mode or elevation; a directory junction is an alternative that needs neither. The existing `validate_repos_dir` logic is platform-independent and could be lifted out of `#[cfg(unix)]` as-is.
- **Or surface the limitation.** Hide or disable the field on Windows, or return a clear error on save, so the setting never appears to succeed while doing nothing.

Happy to hear which direction maintainers prefer before anyone writes a patch — the "implement it" path has a real decision in it (symlink vs. junction, and what to do when symlink creation is denied).