Windows: WakaTime not tracking reliably in non-git projects due to incorrect absolute path handling (WASM)

[aashishbishow]

##Description
I’m seeing unreliable / missing WakaTime tracking on Windows, especially in non-git projects. After digging into the extension code, this appears to be caused by incorrect absolute path handling in the WASM environment.

##Root cause
On Windows, Zed (WASM) can return paths in the form:
/C:/Users/.../wakatime-cli.exe

These paths are already absolute, but the extension’s absolute-path detection does not recognize this format. As a result:
The path is treated as relative
It gets incorrectly join()ed with current_dir()

This produces invalid paths like:
\C:\Users...\wakatime-cli.exe

Additionally, the sanitize_path() logic mutates Windows paths by stripping leading /, which can further corrupt already-invalid paths.
Why this shows up mostly in non-git projects
In git repositories, WakaTime often succeeds via git-based project discovery, which can mask the issue.
In non-git projects, WakaTime relies more heavily on:
cwd
explicit paths
.wakatime-project
When the CLI path is invalid, heartbeats fail silently. Creating a .wakatime-project works as a workaround because it bypasses git/cwd inference, which is why it appears to “fix” the issue.

##Suggested fix
Treat /C:/... paths as absolute on Windows/WASM
Avoid joining already-absolute paths with current_dir()
Remove path string sanitization and rely on Path semantics

##Environment
OS: Windows 11
Zed: v0.217.2(latest)
WakaTime extension: v0.1.10(latest)
Reproducible mainly in non-git folders

##Notes
This is subtle and Windows-specific, but once fixed, WakaTime behaves consistently in both git and non-git projects.