fix(reliability): redact hostile Hangul option access failures

[seonghobae]

Current authoritative state

This hostile-option-access defect is repaired on the existing canonical single-writer Draft PR #320 / branch feat/hwp-hwpx-authoring. Protected shipped truth remains main@3b38ead2d00f44eb578d0689087b9293b3dabe1e; current exact Draft head is 5ee6e4d0c3b2a804f39a8d186a8bdd7c2a38a782.

Current src/hangul/index.ts uses module-owned readHangulOption() for the host-supplied engine, import maxSourceBytes, export maxOutputBytes, and export format reads before those values cross into engine/resource authority. If an accessor or Proxy trap throws, Inkspan catches the unknown thrown value without reading, stringifying, coercing, enumerating, or prototype-inspecting it and raises the stable payload-redacted HangulDocumentError('INVALID_CONFIGURATION', 'Hangul options are invalid.').

Numeric byte-limit validation and its existing messages remain authoritative after a successful read; omitted/default HWPX selection and explicit HWP/HWPX semantics are unchanged. Cleanup containment (#365), finite structural-metadata ceilings (#367), supported-content behavior, standalone/no-network operation, and host-owned engine authority remain preserved.

This is Inkspan-owned local argument/error-containment scope. Hosts still own the actual HWP/HWPX engine, filesystem/network/WASM initialization, credentials, persistence, publication, and telemetry.

Test-first lineage

• RED 907b088a77a6c0324b2907cba13235da8d508e58 proved hostile getters for maxSourceBytes, maxOutputBytes, and format could leak private thrown values before engine authority.
• GREEN 0786240d8e30e66effd8326fad3d5d67af427f4d added module-owned readHangulOption() containment with stable INVALID_CONFIGURATION semantics.
• Current exact head 5ee6e4d0c3b2a804f39a8d186a8bdd7c2a38a782 carries that repair together with later feat(hangul): import, edit, and export HWP/HWPX #320 engine-boundary and documentation hardening; predecessor workflow/review evidence does not transfer after head movement.

Exact-current-head evidence

For unchanged exact head 5ee6e4d0c3b2a804f39a8d186a8bdd7c2a38a782 against protected main@3b38ead2d00f44eb578d0689087b9293b3dabe1e at the latest fresh refetch:

• CI 32395091285: completed / success; build/test 96510085342 checked out the exact head and completed 161 files / 898 tests at 100% statement/branch/function/line coverage, with package/build verification;
• Office Python 3.11-3.14 and cross-engine Playwright jobs: completed / success;
• Security Scan 32395091192: completed / success;
• SAST Semgrep 32395091052: completed / success;
• qualifying latest-push independent approval remains absent / non-passing;
• GitHub reports the Draft mechanically mergeable, which is not integration authorization.

All observed repository-owned exact-head workflows are terminal success. The absent qualifying approval remains non-passing; repository technical success does not replace separately applicable central or review governance.

Integration boundary

The behavioral defect is repaired on active Draft #320 but is not protected-main shipped behavior. Keep this issue open until #320 integrates under live governance. Keep #320 Draft/unmerged while #118 owns the frozen v0.6.0 publication/provenance boundary. Any #320 head/base/ruleset movement invalidates corresponding exact-head evidence and requires fresh revalidation. Do not create a competing Hangul writer, transfer predecessor evidence, self-approve, weaken gates, move protected main, or fabricate release identity.