feat(form_fit): lay out Hancom's automatic spacing between Hangul and Latin or digits

[airmang]

무엇

문단 모양이 한글·영문/숫자 자동 간격(hh:autoSpacing eAsianEng·eAsianNum)을 켜면 한/글은:

• 한글 음절 바로 옆의 영문 글자(eAsianEng) 또는 숫자(eAsianNum) 사이에 em의 1/4을 넣는다. 자간은 간격에도 적용되고 장평은
  간격을 바꾸지 않는다. 빈칸·문장 부호가 사이에 있거나, 영문과 숫자 사이, 전각·기호 글자(Ⅱ ① ｱ) 옆에는 넣지 않는다.
• 그 간격은 앞 글자에 붙는다: 줄이 그 자리에서 나뉘어도 앞 글자는 간격까지 들어가야 그 줄에 남는다.

FormFit은 자동 간격을 몰라, 그런 문단의 줄이 한/글보다 늦게 나뉘었다.

• TextStyle.auto_space_latin·auto_space_digit(text_style_from_refs가 문단 모양에서 채움), auto_space_gap(previous, ch, font_pt, style).
• hancom_line_starts가 글자마다 그 뒤 간격을 함께 넣어 센다.

줄 배치 정보 쓰기의 탭 폭 계산은 아직 간격을 넣지 않는다(자동 간격 문단은 #514가 건너뛰게 함).

시험

• test_automatic_spacing_puts_a_quarter_em_between_hangul_and_latin_or_digits, test_an_automatic_space_goes_with_the_character_before_it
  (고치기 전 실패).

🤖 Generated with Claude Code

[airmang]

Reviewed exact head a484030, appended TextStyle flags, paragraph-shape parsing, automatic-gap boundaries and measurement consumers. All 206 local FormFit/cache tests and all 13 current CI checks pass; workflow head SHA verified and logs inspected (6,934 passed, 18 skipped, 1 xfailed; coverage 90.05%, lint/types/hygiene pass). Found a reproducible public-width/confidence inconsistency after enabling the new gap rule; hold for the inline finding. The description also correctly identifies #514 as a prerequisite while tab-width calculation lacks these gaps. COMMENT because this account owns the PR.

[airmang]

[P2] Include the same automatic gaps in width and confidence measurement. hancom_line_starts now adds these gaps, but estimate_text_width still sums only char_advance, and measure uses that old width for ratio and its error-band confidence. Reproduced with text='가A'10, font_pt=10 and TextStyle(auto_space_latin=True): reported width remains 17000 (identical to spacing off), while the new rule adds 19250=4750, giving 21750. A one-line SlotMetrics(available_width=23000,...) consequently returns confidence='high' and ratio=0.739, even though the modeled width is within the 11.18% uncertainty band (21750/23000=0.946). Update the width/confidence path to include applicable gaps and add a public measure/estimate_text_width regression; line-start-only tests miss this inconsistency.

[airmang]

Re-reviewed exact new head 6d3b24b and its range-diff against the prior review. Changes are base/CHANGELOG or fixture-list integration; the implementation underlying the existing unresolved inline finding is unchanged.

Automatic gaps still disappear from public estimate_text_width/measure confidence: 가A repeated ten times reports 17000 instead of the new-rule 21750, and the 23000-wide slot still reports high confidence. #514 is now merged, so that safety prerequisite is fulfilled; this separate width/confidence defect remains. Hold remains; no duplicate inline thread added.

All 208 related local tests pass. All 13 exact-head CI checks pass; workflow head SHA verified and test/lint/type/hygiene logs inspected (6,939 passed, 18 skipped, 1 xfailed). Those checks do not cover the reproduced finding. COMMENT because this account owns the PR.

[airmang]

Revalidated exact rebased head d8f3480. Read the range-diff and surrounding affected code; changes since the prior review are base/CHANGELOG or fixture-test placement only. Re-ran the existing targeted reproduction at this exact head. The unresolved automatic-gap width/confidence inconsistency remains: 가A repeated ten times reports width 17000 rather than 21750 and high confidence for a 23000-wide slot. #514 is present in the new base; it does not fix this measurement path.

All 13 current CI checks pass; verified the successful workflow's head SHA and read its test/lint/type/hygiene log (6,946 passed, 18 skipped, 1 xfailed; coverage 90.06%). The existing inline finding remains unresolved; hold remains and no duplicate inline thread is added. COMMENT because this account owns the PR.