feat: validate paid custom learning packs

[fly1d]

What changed

• Offer a CNY 29 concierge learning pack after a successful free summary: a focused route, 10 flashcards, 5 explained quiz questions, and one practical task.
• Collect explicit purchase intent with the topic, goal, contact method, and consent; clearly state that submission does not charge the user.
• Store only the minimum lead fields in a private JSONL file with validation, control-character cleanup, a honeypot, bounded requests, global rate limits, and 0600 permissions.
• Record identity-free offer-view and form-open events, add a local conversion report, and add a separate command for recording confirmed payments without duplicating contact data.
• Restrict static file serving to the three public UI assets so lead files, server source, and Git metadata cannot be downloaded.
• Document the first-sale outreach, fulfillment workflow, privacy responsibilities, and seven-day decision thresholds.

Closes #13

Risk

• Low: copy, styles, documentation, or isolated cleanup
• Medium: interaction, API response, or shared behavior
• High: fetching, security boundary, deployment, or data compatibility

Verification

• npm run ci passes locally
• I tested the main user path affected by this change
• I checked desktop/mobile layout when UI changed
• I added or updated tests for behavior changes
• I documented anything intentionally not tested

Verification notes:

All 20 local checks pass. Automated tests use a real server and temporary data files to verify minimal lead fields, explicit consent, control-character cleanup, identity-free commercial events, 0600 permissions, no automatic charge, and 404 responses for .data, server.mjs, and .git/config. The payment ledger rejects duplicate confirmation and the report separates intent from confirmed revenue.

Browser testing covered analysis, the visible CNY 29 offer, default-unchecked required consent, a complete test submission, success reference and no-charge copy, desktop and 390x844 layouts, no horizontal overflow, and no console warnings/errors. Browser test records were stored only in /tmp and deleted afterward.

Not tested: real payment processing, because this validation release intentionally confirms scope and payment manually before adding a payment provider. Public deployment is also not included and remains the next commercial prerequisite.

Review and release

• The diff is focused and contains no unrelated changes
• Error, empty, loading, and recovery states were considered
• Security and privacy impact was considered
• Rollback is understood

Rollback plan:

Revert this PR to remove the offer UI, APIs, funnel events, and reporting commands. Before reverting a deployed instance, export any legitimate private lead and sales files needed for already-promised fulfillment, then delete the runtime files when no longer required. No public API client or database migration depends on this change.

[fly1d]

Code review completed with no blocking findings. Verified: purchase intent is clearly separated from payment; explicit consent and bounded sanitized fields are required; the lead record contains only seven necessary fields; aggregate funnel events contain only event name and timestamp; IP addresses, User-Agent, source excerpts, and full analysis context are not stored; private files are forced to 0600; static serving is allowlisted and returns 404 for .data, server source, and Git metadata; duplicate payment confirmation is rejected; reporting distinguishes intent from confirmed revenue; all 20 automated checks and the final GitHub Smoke pass; desktop and 390x844 browser checks have no overflow or console errors. Public deployment and real payment processing remain intentionally outside this validation PR.