Fix Kakuyomu Next.js crawling

[AlexbeatsZ]

What changed

• Parse Kakuyomu work metadata and tableOfContentsV2 from the current Next.js __NEXT_DATA__ Apollo state.
• Keep the existing episode-body parser while making its title pattern local under strict mode.
• Use https-proxy-agent for Kakuyomu so HTTPS proxy CONNECT requests include SNI, with support for both proxy environment variables and the existing proxy= CLI argument.
• Treat regenerate as per-run state instead of inheriting it from cached work JSON.
• Ignore generated dependency and Kakuyomu download directories, and document the verified workflow in AIREADME.md.

Why

Kakuyomu's work page no longer exposes the legacy widget-toc-* markup, so the crawler detected zero chapters. CeJS 4.5.10's built-in HTTPS proxy agent also opens TLS without SNI, which CloudFront rejects with a TLS handshake failure.

After an EPUB regeneration, cached regenerate: true was inherited on the next normal run. The crawler then resumed from the last downloaded chapter and rewrote the OPF manifest and spine with only that chapter, making readers show only the final episode.

Validation

• node --check novel.ja-JP/kakuyomu.js
• npm ls cejs https-proxy-agent --depth=0
• Downloaded Kakuyomu work 16818093080247863087: 136 of 136 episodes.
• Rebuilt the EPUB from cache: 137 XHTML manifest entries and 137 spine entries (TOC plus 136 episodes).
• Re-ran the normal download command after regeneration; the EPUB SHA-256 and modification time remained unchanged.
• Confirmed 136 unique chapter files in the EPUB navigation document and sampled the first, middle, and final episode titles.
• 7z t reported Everything is Ok for the generated EPUB.
• Re-ran with proxy=http://127.0.0.1:7897 and confirmed the completed work was detected correctly.