v0.2.5 — live web-port discovery for dsh:// + engines.dsh

Fixes

#2 — DSH Desktop: hardcoded port and a protocol handler owned by the desktop shell

• The landing address no longer hardcodes 3080. The host half publishes the
  live Web URL (webServer.port) to a shared state directory
  (DSH_SESSION_LINK_STATE_DIR → %LOCALAPPDATA%\dsh-session-link →
  %TEMP%\dsh-session-link) as web-url; dsh-open.cmd resolves the base URL
  in order env DSH_SESSION_LINK_WEB_URL → state file → 3080, strips a
  trailing slash, rejects a non-http file, and records the source it used in
  %TEMP%\dsh-open.log (source=env|file|default|default-invalid). The file is
  read with for /f, so CRLF and LF-only files both work.
• register-protocol.ps1 refuses to steal a foreign handler. It reads
  HKCU:\Software\Classes\dsh\shell\open\command, prints the current owner and
  the alternatives, and exits non-zero unless -Force is passed. -Uninstall
  and a -RegistryPath hook (testing) remain.
• READMEs document the DSH Desktop situation (who owns dsh://, the
  -Force trade-off, and why pasting a link needs no protocol at all).

#3 — marketplace compatibility was guessed from peers

The manifest now declares engines.dsh: ^0.1.7-rc.1 || ^0.2.0-rc.2 so a
marketplace can judge compatibility directly. That range is deliberate: it is
the only candidate that matches 0.2.0-rc.2 with and without
includePrerelease semantics (verified against semver), while
>=0.1.7-rc.1 alone fails a plain satisfies() check for 0.2.0-rc.2.

Verification

• 112 PASS / 0 FAIL — adds launcher.test.mjs (static checks plus a Windows
  probe that drives the real batch with start swapped for echo across the
  fallback, the state file with CRLF and LF endings, the env override, and a
  garbage file), host-half web-url publishing (and no file without a
  webServer), and a manifest check for engines.dsh.
• Live on this machine: the running instance wrote
  %LOCALAPPDATA%\dsh-session-link\web-url = http://127.0.0.1:3080, the
  launcher probe picked it up (source=file), /s/<id> still redirects to
  /?session=<id>, and the registration guard was exercised against a scratch
  registry key (refuse → exit 1, -Force takes over, -Uninstall removes).

Full diff: v0.2.4...v0.2.5

v0.2.4 — dsh 0.2.x line support

What changed

dsh 0.2.0-rc.2 keeps every client/host seam this plugin uses
(ctx.uiWorkspace.openSession, the sessions list store, slots, and the
host's sessionReferenceResolver / webServer routes), so no code change was
needed — only the declared ranges: a caret on ^0.1.7-rc.1 cannot match
0.2.0-rc.2, which made pnpm warn about every client peer.

• spans ^0.1.7-rc.1 || ^0.2.0-rc.2 for the session-reference dependency and
  the client peer packages (both dsh lines are now supported)
• READMEs + cordis.patch.yml document the supported lines
• client-half.test.mjs asserts the widened ranges
• pnpm-lock.yaml resolves the dev/test packages to 0.2.0-rc.2

Verification (dsh 0.2.0-rc.2)

• 88 PASS / 0 FAIL (host-half + client-half + resolver-integration)
• GET /s/<id> still answers 302 → /?session=<id>
• the served client bundle carries the uiWorkspace opener (no sessions.open)
• a real browser session opened from a ?session= deep link end to end

Full diff: v0.2.3...v0.2.4

v0.2.3 — dsh 0.1.7 session navigation

What changed

dsh 0.1.7-rc.1 removed ctx.sessions.open() and moved session navigation to
the retain/reference model, so the browser deep-link opener now navigates
through ctx.uiWorkspace.openSession() (declared via dependency injection),
wrapped in a ctx.effect with bounded lifecycle retries: queued retries are
cancelled on dispose and navigation happens exactly once.

• requires dsh >= 0.1.7-rc.1 for the navigation seam
• client-half.test.mjs drives the opener against a fake context deliberately
  without sessions.open (URL forms, delayed catalog, transient failures,
  bounded ~10 s budget, teardown/disposal guards, exactly-once navigation)
• carried from 0.2.2: ?session=<id> deep links, the legacy /s/<id> → 302
  redirect, and ?session= reference parsing

Full diff: v0.2.2...v0.2.3

v0.2.2 — browser deep links fixed for dsh >= 0.1.1-rc.2

Fix

dsh 0.1.1-rc.2 removed the frontend SPA fallback: unknown paths (including
/s/<sessionId>) now answer 404, and only the index route boots the app.
The dsh:// protocol handler and every pasted /s/<id> link therefore stopped
opening a session.

• dsh-open.cmd — opens /?session=<sessionId> instead of /s/<sessionId>,
  validates the input, and keeps redirection/grouping characters out of the
  header comments (batch parses them inside rem lines too)
• lib/client.js — the deep-link opener now reads ?session=<id> plus the
  legacy /s/<id> path and the #/s/<id> / #session=<id> hashes
• lib/index.js — ?session= web links pasted into a prompt are parsed as
  session references, and a best-effort /s/<id> → /?session=<id> 302
  route keeps old links, bookmarks and history entries working (skipped in
  compositions without webServer)
• Tests: 47 PASS / 0 FAIL (four URL forms + the redirect route)
• README (zh/en) and register-protocol.ps1 updated

修复说明（中文）

dsh 从 0.1.1-rc.2 起移除了前端 SPA fallback：未知路径（含 /s/<会话ID>）一律
404，只有 index 路由能启动应用，于是 dsh:// 链接和旧式 /s/<id> 链接都打不开会话。
现在浏览器地址改用 /?session=<会话ID>，旧链接由插件 302 重定向兜住；消息里粘贴
?session= 形式的地址也能作为会话引用解析。

Compatibility

• requires dsh ≥ 0.1.0-rc.8 (the shipped web bundle provides session-reference)
• the browser deep link needs the browser to hold this dsh web's login cookie
  (visit the token URL printed by dsh web once)

Full diff: v0.2.1...v0.2.2