refactor: CLI js 與 exec js step 的語意分歧（#76 後：statement-wrap vs raw completion-value）需對齊或明文化 (follow-up from #76 verify)

[kiki830621]

Problem

#76 把 CLI js 從頁面 context eval() 改為 expression-first + statement-wrap（多 statement 需顯式 return），但 exec script 的 js step（Sources/SafariBrowser/Exec/InProcessStepDispatcher.swift:58）仍直接把 raw code 傳給 SafariBridge.doJavaScript — 保留 completion-value 語意。兩個 js 入口對同一段代碼的結果自 #76 起分歧：

Input	CLI js (#76 後)	exec js step
var a=2; a+3	undefined（需 return）	5.0（completion value，AppleScript 數字格式）

（daemon 路徑無此分歧 — DaemonRouter 在 AppleScript-source 層 route，CLI-direct 與 CLI-via-daemon 一致，#76 verify devil's advocate 已確認。）

Type

refactor（cross-surface 語意一致性）

Expected

擇一（需 design 決策，不宜倉促）：

1. exec js step 走同一套 JSWrapper 協定 → 完全一致，但這對 exec 既有使用者也是 breaking change（多 statement 需 return），且 exec step 需要 wrapper 的 error/result 協定支援
2. 明文接受分歧為兩 surface 的既定語意（exec = raw completion-value；CLI = wrapper 語意），在 exec spec（openspec/specs/script-exec/spec.md）與 README 雙邊 normative 記載

README 已於 #76 verify round 加上暫時性的分歧說明（### JavaScript 段落）；本 issue 決定長期方向。

Impact

在 CLI 與 exec 間搬移 js snippet 的使用者會遇到 silent 結果差異（一邊有值、一邊 undefined），無錯誤提示。

Source: surfaced during /idd-verify #76 (devil's advocate finding, follow-up filed per Step 5b)