get_process_cwd() uses lsof on Windows, causing OpenCode sessions to never be displayed

## Bug Description

On Windows, btop always shows **0 sessions** for OpenCode (and potentially other agents that rely on cwd matching), even when opencode.exe is running and the SQLite database is correctly populated.

## Root Cause

In src/collector/opencode.rs, the get_process_cwd() function has only **two platform branches**:

- #[cfg(target_os = "linux")] – reads /proc/<pid>/cwd (works)
- #[cfg(not(target_os = "linux"))] – calls lsof -a -p <pid> -d cwd -Fn (fails on Windows)

There is **no #[cfg(target_os = "windows")] branch**, so the function always returns None on Windows because lsof does not exist there.

## Impact

PID-matched sessions are silently dropped in collect_sessions():

`
ust
let Some(matched_pid) = matched_pid else {
continue; // ← session is silently discarded
};
`

The fallback cmd.contains(session_dir) also fails because the opencode.exe command line is just the binary path without any project directory.

## Steps to Reproduce

1. Install abtop on Windows
2. Start an opencode session
3. Run btop --once
4. See: "0 sessions" despite opencode.exe running and opencode.db correctly populated

## Proposed Fix

Add a Windows-specific get_process_cwd() using sysinfo (already a dependency in [target.'cfg(target_os = "windows")'.dependencies]):

`
ust
#[cfg(target_os = "windows")]
fn get_process_cwd(pid: u32) -> Option {
use std::sync::{Mutex, OnceLock};
static SYS: OnceLock> = OnceLock::new();
let sys_mutex = SYS.get_or_init(|| Mutex::new(sysinfo::System::new()));
let sys = sys_mutex.lock().ok()?;
let pid = sysinfo::Pid::from(pid as usize);
sys.process(pid)?.cwd().map(|p| p.to_string_lossy().into_owned())
}
`

This mirrors the pattern already used in:
- src/collector/claude.rs – map_pid_to_sysinfo_open_paths()
- src/collector/process.rs – get_process_info() on Windows

## Environment
- Windows 11
- abtop v0.4.8
- opencode latest