fix(text): decode Latin-1 and other single-byte txt files instead of GB18030

[4gray]

Summary

• options.text.encoding: 'auto' resolved every buffer that is not UTF-8 or UTF-16 to GB18030, so an ISO-8859-1 / Windows-1252 txt file rendered Saarbrücken as Saarbr點ken. The union offered no single-byte encoding, so nothing could correct it.
• Add iso-8859-1, iso-8859-2, iso-8859-15, windows-1250, windows-1251, and windows-1252 to text.encoding, with common aliases such as latin1, cp1252, and cp1251.
• Add options.text.fallbackEncoding, the decoder auto uses for bytes that are not valid UTF-8. It defaults to gb18030, so existing GBK files render exactly as before. Single-byte text is structurally valid GB18030, so it cannot be detected from the bytes; the fallback is an explicit option, not a heuristic.
• Thread the fallback through the code, Markdown, HTML source, XML, patch, and virtual large-text paths. The large-text renderer now treats single-byte encodings as one byte per character when slicing long lines and when mapping search matches to byte offsets; it previously reused the UTF-8 continuation-byte alignment, which skipped 0x80–0xBF bytes at segment starts.
• resolveFileViewerTextEncoding and decodeFileViewerTextBuffer take an optional third fallbackEncoding argument; isSingleByteFileViewerTextEncoding and DEFAULT_FILE_VIEWER_TEXT_FALLBACK_ENCODING are exported. Download still returns the original bytes.

Related issue

N/A: the bug report was received outside GitHub (renderer-text 2.3.0 / core 3.1.2, Latin-1 umlauts decoded as GB18030); the reporter's reproduction is committed as test/fixtures/text-encoding/latin1-umlauts.txt and reproduced from the library decode path on main.

Change classification

• User-visible UI or rendering change
• Non-visual change
• File-format or renderer behavior
• Public API, package, Worker, WASM, or deployment-path change

Verification

Check	Result
pnpm install --frozen-lockfile	Pass
pnpm exec vitest run test/text-single-byte-encodings.spec.ts (9 tests: resolver, aliases, UTF-8/BOM/UTF-16 precedence, jsdom virtual large-text segments and search)	Pass
pnpm exec vitest run test/core-options.spec.ts test/html-preview.spec.ts test/text-single-byte-encodings.spec.ts (17 tests)	Pass
pnpm type-check:core	Pass
pnpm --filter @file-viewer/renderer-text type-check	Pass
pnpm type-check	Pass after pnpm --filter @file-viewer/asset-installer build; on a cold checkout packages/tools/assets-standard fails first because the unbuilt @file-viewer/asset-installer workspace package is missing, which is unrelated to this change
pnpm build:core	Pass
pnpm --filter @file-viewer/renderer-text build (tsc plus 12 node tests)	Pass
pnpm docs:build	Pass
Mutation check: with the two single-byte branches in largeText.ts disabled, the segment-slicing and search tests fail (' ' instead of «»…, 138 matches instead of 200)	Pass

Sample / fixture evidence

• Repository fixtures: test/fixtures/text-encoding/latin1-umlauts.txt (ISO-8859-1, the reporter's sentences) and test/fixtures/text-encoding/windows-1251-cyrillic.txt (Windows-1251), with a README that records the iconv commands used to generate them. Both are original text written for this repository.
• The Vitest suite also builds a 3000-byte «» line in memory so segment boundaries land on bytes that look like UTF-8 continuation bytes.

Visual evidence

• Before / After (same viewport, real renderText from @file-viewer/renderer-text on latin1-umlauts.txt in Chrome):

Left: default auto still shows Saarbr點ken (unchanged default). Right: text.fallbackEncoding: 'windows-1252' shows Saarbrücken, Fußgänger, Nächste, öffnet, Büro, Nähe.

Risk and compatibility

• Affected packages/formats: @file-viewer/core (FileViewerTextOptions, text encoding resolver, new exports), @file-viewer/renderer-text (txt/code, Markdown, HTML source, XML, patch, virtual large text). CSV / TSV keep their separate spreadsheet.textEncoding union and are unchanged.
• Compatibility or migration risk: fully additive. The default fallback stays gb18030, the new function parameters are optional with the old default, and the existing union members keep their meaning. Browsers decode the iso-8859-1 label with the windows-1252 table per the WHATWG Encoding Standard, which is documented. Component wrappers pass options.text through untouched, so no wrapper changes are needed.
• Rollback: revert the single commit; no data, asset, or API migration is involved.

Checklist

• I added or updated focused automated coverage, or explained why it is not needed.
• I updated user-facing documentation or release notes when behavior or API changed, or marked them not applicable.
• I verified offline/private-deployment paths when changing Worker, WASM, fonts, vendor assets, or URLs.
• I did not commit secrets, customer files, private samples, generated caches, or unrelated changes.

🤖 Generated with Claude Code

[wybaby168]

Thanks @4gray. The complete change at b957c2be56e753a05889fbb3828e950cc4277d1d has been compared against main fc2a7487dfc1ba26a3c929509df463e9cc3256c3. The public decoder/export APIs, fallback forwarding, single-byte segment/search handling, binary fixtures and original regression cases are preserved in the adapted implementation. main also retains later Markdown behavior and adds charset, BOM/UTF-16 and exact byte-offset coverage.

#360 preserves your original 31,501-byte before/after image without modification, under docs/regressions/text-single-byte-encodings/original-before-after.png, with your attribution and original commit recorded in the regression documentation. The complete main CI has passed, including the actual text regression gates. Closing as fully incorporated; this does not request deletion of your fork branch or dismiss any historical review.