## 문제
합산기호 ∑(및 ∏·∫)의 피연산자가 연산자에 붙어 렌더됨(예: 6쪽 문26 "∑bₙ의").
한컴 PDF 정답지는 적정 간격을 둠. (edwardkim#1224 폰트 조사 중 발견 — 폰트 무관.)

## 원인
equation/layout.rs::layout_row 는 형제 노드를 x += b.width 로 간격 0 배치 → 큰
연산자-피연산자 간격은 BigOp 박스 width 가 결정. 그러나 limits(layout_big_op)·적분
(layout_integral, bare 적분)의 width 에 trailing 간격이 없어 피연산자가 붙었다.
(일반 연산자 + - = 는 layout_symbol 에서 pad 를 가지나 큰 연산자만 누락.)

## 해결
- BIG_OP_TRAIL_PAD(=0.45, fs 비율) 도입, 큰 연산자 3경로(layout_big_op·layout_integral·
  bare 적분) box width 에 trailing 간격 추가.
- 렌더러(svg_render/canvas_render) 보정: limits 연산자를 lb.width 가 아닌
  max_w(= lb.width - fs*PAD)에 중앙정렬 → pad 전체가 순수 trailing 이 되고 ∑이 첨자와 정렬.
- WASM(canvas) 경로 동일 적용.

## 안전성 (자기완결)
인라인 수식은 svg.rs/web_canvas.rs 에서 scale_x = tac_w/layout_box.width 로 가로 스케일되어
tac_w 에 맞춰지므로, BigOp width 증가는 오버플로(다음 글자 침범) 없이 흡수되고 간격만
비례적으로 생긴다. 문단 advance·메트릭 DB·페이지네이션 무변경.

## 검증
- 시각: 첫 ∑(·둘째 ∑bₙ·적분 ∫ 모두 간격 생성, ∑이 첨자와 정렬, 과간격 없음 (SVG/WASM).
- 레이아웃 불변: dump-pages base 대비 바이트 동일.
- cargo test --lib equation 139 passed, 0 failed (신규 단위 테스트 포함).

## pad 값 이력
0.1(초기) → 0.25(압축 큰 수식 보강) → 0.45(작업지시자 시각 판정). 큰 수식은 scale_x(0.6~0.9)
압축으로 pad 가 약화되므로 압축 후에도 충분한 간격이 남는 값으로 확정.