PR #1673 added sanitizeHeadersForBrowser in the fetch bridge to handle
non-ISO-8859-1 directory paths by encoding the value and attaching a
x-opencode-directory-encoding: uri header. The server-side decoder was
already in place (08b86613). However, the CORS Access-Control-Allow-Headers
list on the Express server was not updated to include this new header.
When a user opens a directory with CJK or other non-Latin-1 characters
(e.g. D:\文件), the browser sends a CORS preflight OPTIONS request with
x-opencode-directory-encoding in the Access-Control-Request-Headers.
The preflight fails because the server does not list it as allowed,
blocking all subsequent API requests with 'Failed to fetch'.
Add X-OpenCode-Directory-Encoding to the Access-Control-Allow-Headers
response header for openchamber-ui://app packaged client origin.
* fix: handle non-ISO-8859-1 characters in fetch headers and Content-Disposition
Browser Headers API rejects characters above U+00FF. The x-opencode-directory header carries raw filesystem paths, which breaks when paths contain Chinese/CJK characters. Also fixes Content-Disposition for non-ASCII filenames per RFC 5987.
* refactor: export header sanitization helpers, deduplicate, add tests
Export isLatin1Safe and sanitizeHeadersForBrowser from runtime-fetch.ts so VS Code webview can import them instead of duplicating the logic. Add tests: isLatin1Safe boundary checks, sanitizeHeadersForBrowser encoding/deduplication, runtimeFetch round-trip encode/decode, and Content-Disposition RFC 5987 output for both ASCII and non-ASCII filenames.
* fix: mark encoded directory headers
---------
Co-authored-by: Bohdan Triapitsyn <artmore@protonmail.com>
FanFan4204