Release v0.7.2: npm 패키지 배포 준비 — @rhwp/core + @rhwp/editor + VS Code 0.7.2

Windows 환경에서 cfb 크레이트 동작 시 발생하는 역슬래시(\) 경로 구분자 문제를 슬래시(/) 단위로 일일이 변경하여 모든 OS 환경에서 일관된 경로를 보장하도록 함.

Problem
-------
HwpxReader::read_file and read_file_bytes called read_to_string /
read_to_end directly on zip::ZipFile readers with no size ceiling.
ZIP allows extreme compression ratios, so a few-KB .hwpx can claim a
single section.xml entry that expands to multi-GB — OOMing the host.
Any downstream (CLI, WASM, browser extension, VS Code) inherits the
risk since all of them funnel through parse_hwpx → HwpxReader.

Fix
---
Introduce a small read_limited(reader, max) helper using Read::take
so we never allocate past max+1 bytes. Apply:

  - MAX_XML_SIZE     = 32 MB  for text entries (section/header/hpf)
  - MAX_BINDATA_SIZE = 64 MB  for binary entries (images, fonts)

Real-world Korean government HWPX (보도자료·법령·판례) stays well under
these, so legitimate files are unaffected. Over-limit entries surface
as HwpxError::ZipError with "decompression bomb" in the message —
callers see a clean parse error instead of a crash.

Rationale for thresholds
------------------------
MDM (https://github.com/seunghan91/markdown-media) has been running
the same 32/64 MB caps in production across ~500 real HWPX fixtures
with zero false positives; see MDM commit a94b459 for the original
application of this pattern across HWP/HWPX/PDF parser paths.

Tests
-----
Five unit tests in parser::hwpx::reader:
  - under / at / over cap boundary for read_limited
  - a synthetic zip-bomb entry (MAX_XML_SIZE + 1 bytes of 'A',
    compressed to <1 MB) is rejected with ZipError

Full suite: 789 passed, 0 failed (baseline + 5 new).

No public API change: HwpxError variants unchanged, method signatures
unchanged. MAX_XML_SIZE / MAX_BINDATA_SIZE are exposed as pub const
so integrators can read the current caps.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Problem
-------
parser/hwpx/header.rs:293 treats any shape != "NONE" | "3D" as a real
strikethrough:

    cs.strikethrough = !matches!(val.as_str(), "NONE" | "3D");

This is a blacklist of known placeholders. It is correct for the 3D
case Hancom emits today, but fails open: any future placeholder value
Hancom adds (e.g. "4D", "Ghost", internal experiments) will be
misinterpreted as a real strike line, and entire body-text paragraphs
will render with strikethrough.

Fix
---
Flip the predicate to a whitelist of OWPML LineSym2 values that shape.rs
already recognises (SOLID, DASH, DOT, DASH_DOT, DASH_DOT_DOT, LONG_DASH,
CIRCLE, DOUBLE_SLIM, SLIM_THICK, THICK_SLIM, SLIM_THICK_SLIM, WAVE,
DOUBLE_WAVE — 13 entries, same set as the enum mapping immediately
below). Unknown values — including NONE, 3D, and any future Hancom
placeholder — are fail-closed to no-strike.

Extracted into a `pub(crate) fn is_real_strike_shape(&str) -> bool`
so the predicate is independently testable and can be reused if other
parsers (e.g. underline, which has the same blacklist risk) adopt the
same approach later.

Evidence
--------
MDM (https://github.com/seunghan91/markdown-media) hit the exact same
bug earlier this month. Hancom's HWPX exporter writes <hh:strikeout
shape="3D"/> as a placeholder default on body-text charPr definitions.
Treating "anything but NONE" as strike caused press-release bodies
(e.g. "251113 벤처투자 보도자료") to render wrapped in ~~...~~.

Our fix (MDM commit ae15dd8) moved to the whitelist approach and
verified across 21 MOIS HWPX fixtures: zero false strikes remained.
The same logic fits rhwp one-for-one, so we're upstreaming it.

Tests
-----
Five new unit tests in parser::hwpx::header::tests:
  - all 13 valid OWPML LineSym2 shapes → true
  - "NONE" → false
  - "3D" → false (the original bug)
  - fail-closed cases: "4D", "Ghost", "", "solid" (case-sensitive)

Full suite: 789 passed, 0 failed.

No behaviour change for files Hancom currently emits — the set of
shapes that produce strike=true is identical to the old blacklist
path for every value shape.rs knows about. The only difference is
forward-compatibility: unknown future placeholders no longer get
mis-rendered as strike.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

…eparator

fix(parser): Windows 환경의 CFB 경로 구분자 오류 수정

…otection

fix(hwpx): cap ZIP entry decompression to defeat zip bombs

…-whitelist

refactor(hwpx): whitelist strikeout shapes instead of blacklist

Release v0.7.3 (라이브러리) / v0.2.0 (확장)

Hotfix v0.2.1 (확장): 매뉴얼 §5.1 누락 버전 보강

라이브러리/확장 이원화 정책에 따라 버전 표기 정리:
- 라이브러리 v0.7.3 (Cargo, npm/core, npm/editor, vscode, studio)
- 확장 v0.2.1 (chrome, safari) — Chrome Web Store / Edge Add-ons 심사 진행 중

문서 갱신:
- README.md / README_EN.md / rhwp-chrome/README.md: 변경 이력 + 향후 예정 + 외부 기여자 6명 누적 명시
- mydocs/orders/20260419.md: v0.2.1 표기로 일관성 정리
- mydocs/plans/task_m100_196.md, working/stage3, report: v0.2.1 표기

스토어 등록 정보 (mydocs/feedback/, mydocs/release/):
- kor_desc_0.2.1.md, eng_desc_0.2.1.md: 한국어/영어 마켓 설명 (HWPX 베타 안내 + 기여자 + PR 번호)
- cert_notes_0.2.1.md: 심사용 Notes for certification (1986 chars)
- add_desc_02.md: 변경 사항 추가용 텍스트
- release_notes_v0.7.3.md: GitHub Release 노트

다음 사이클: v0.7.5 통일 (라이브러리 + 확장 단일 버전 정책)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs + CodeQL fix: v0.7.3 회고 보고서 + build.mjs alert edwardkim#16 fix

Add a roundtrip regression test that verifies paragraphs containing line breaks keep their text and char offsets after serialize and reparse.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Keep HWPX paragraph offsets and char shape positions aligned with the original text/control order so linebreak and embedded control roundtrips remain stable.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>