Fix Windows relative bind mounts rejected for extended-length path prefix

[jssblck]

Why

On Windows, a service with a relative bind mount (volume=./seed:/docker-entrypoint-initdb.d) fails at eph up (issue #44):

Error: failed to create container
Caused by:
    Docker responded with status code 500: \?\C%!(EXTRA string=is not a valid Windows path)

Workspace::from_path canonicalized with std, which on Windows returns the extended-length \?\C:\... form and stores it in Workspace::path. A relative bind resolves against that root, so eph forwarded \?\C:\... to Docker as the bind source, which the daemon rejects. (The %!(EXTRA ...) garble is an upstream moby fmt artifact, reproducible with a bare docker run -v.) The prefix also leaked into eph check and eph status output.

What Changed

• Canonicalize with dunce::canonicalize in Workspace::from_path and Watch::new. It returns a plain C:\... path whenever one exists (the common case), keeping \?\ only for paths that genuinely require it. This fixes bind sources, display output, and compose/build current_dir at the source. On Unix it is std::fs::canonicalize (no behavior change).
• resolve_volume_spec is now fallible. A boundary guard (reject_verbatim_bind_source) rejects any host source still carrying \?\ (the genuine long-path fallback) with an actionable message, instead of handing Docker a source it only rejects cryptically. The relative join uses to_str() so a non-UTF-8 path errors rather than silently mounting a lossy source.
• Documented the fix and the workspace-id churn in the troubleshooting guide.

Designed and reviewed in collaboration with Codex (gpt-5.5).

Testing

• cargo test --lib (96 pass, including two new regression tests: a clean Windows root resolves without the prefix, and a verbatim root is rejected), cargo test --doc (7 pass), cargo clippy --all-targets (clean).
• Live on Windows 11 with Docker Desktop 29.5.3: reproduced the issue's exact .eph (named pgdata + volume=./seed:/docker-entrypoint-initdb.d). eph up now succeeds (was a 500). docker inspect shows a clean bind source, and the seed table created by the bind-mounted init script exists in postgres. eph check / eph status print C:\Users\... with no \?\.

User-Facing Or Compatibility Impact

• Relative bind mounts now work on native Windows.
• eph check / eph status no longer show the \?\ prefix.
• Windows-only breaking change: the workspace id is derived from the path string, so dropping \?\ changes the id. Containers, named volumes, and the state directory created by an older build live under the previous id and are orphaned; they need manual docker cleanup. Named volumes did work before, so this only matters for services already running under an older build. Documented in the troubleshooting guide.
• Absolute Windows bind sources (volume=C:\data:/x) remain unsupported: they route to the named-volume branch and the drive-letter colon breaks splitn. That is a separate pre-existing bug, out of scope here; a real volume-spec parser is the proper fix.

Fixes #44