pdf skill: generated Japanese (CJK) PDFs show blank/missing text in Adobe Acrobat — embedded Noto Sans JP CID/CFF subset not rendered

## Summary
PDFs generated through the `pdf` skill workflow that contain Japanese (CJK) text fail to display the text in Adobe Acrobat / Acrobat Reader. Background boxes, icons, lines, and Latin text render correctly, but **all Japanese glyphs are missing (blank)**. The exact same file renders perfectly in Chrome, on mobile, and in Poppler-based viewers, so the file is not "corrupt" — it is a glyph-rendering incompatibility specific to Acrobat.

## Environment
- Fails in: Adobe Acrobat / Acrobat Reader (Windows)
- Renders fine in: Chrome (built-in PDF viewer), mobile viewers, Poppler (`pdftoppm`)

## Embedded fonts (`pdffonts` output)
All three are subsetted Noto Sans JP, embedded as **CID Type 0C (OT)** (OpenType/CFF) with Identity-H encoding:

```
name type encoding emb sub uni
XSXJRS+Noto-Sans-JP-Bold CID Type 0C (OT) Identity-H yes yes yes
DBYYDN+Noto-Sans-JP-Heavy CID Type 0C (OT) Identity-H yes yes yes
ZGMLVJ+Noto-Sans-JP CID Type 0C (OT) Identity-H yes yes yes
```

## Diagnosis
- Text extraction works (`pypdf` returns the full text; ToUnicode is intact) -> the problem is purely glyph rendering in Acrobat, not the text layer.
- `gs -dNoOutputFonts` (convert text to outlines) **also drops the Japanese glyphs** -> Ghostscript cannot decode the CFF subset either; only Poppler renders it.
- Conclusion: the OpenType-CFF (CID Type 0C) subset embedding produced by the generation toolchain (HTML -> headless Chromium print-to-PDF) is not compatible with Adobe Acrobat's CJK renderer.

## Impact
End users who open Claude-generated Japanese PDFs in Adobe Acrobat (the default PDF app for many users in Japan) see documents with all Japanese text missing — indistinguishable from a corrupted/blank file. This affects any deliverable containing CJK text.

## Workarounds that DO fix it
- Rasterize each page (Poppler, 300dpi) and rebuild as an image-based PDF — displays everywhere including Acrobat, but loses text searchability.
- Re-export via LibreOffice (`soffice --convert-to pdf`) — produces Acrobat-compatible font embedding and keeps searchable text.

## Suggested fix
When generating PDFs that contain CJK text, embed fonts as TrueType (CIDFontType2) rather than OpenType-CFF (CIDFontType0C), or document an Acrobat-compatible generation path in the `pdf` skill.

Start by reproducing the pdf skill workflow with Japanese text, then inspect the generated PDF using pdffonts and Acrobat/Acrobat Reader on Windows. The issue points to the HTML-to-headless-Chromium print-to-PDF path and Noto Sans JP CID Type 0C embedding. Done means CJK PDFs render in Acrobat with searchable text, or the pdf skill documents an Acrobat-compatible generation path.

索引モデルが issue の本文から書いたものです。