Testing: scheduled long-running fuzz campaigns

[dvershinin]

Context

Follow-up from #51. The current fuzz CI runs each target for 60 seconds per PR, which is good for regression but insufficient for deep coverage exploration.

Proposal

Add a scheduled GitHub Actions workflow (e.g. weekly cron) that:

1. Runs each fuzz target for a longer duration (e.g. 30 minutes)
2. Stores the accumulated corpus as a build artifact or in a dedicated branch
3. Re-uses the corpus across runs for incremental coverage growth
4. Opens an issue automatically if any crashes are found

Reference

The current fuzz infrastructure is in fuzz/ with make fuzz-run FUZZ_DURATION=<seconds>.

[github-actions]

Thank you for opening this issue.

This project is maintained by a single developer in their free time.
Upstream TelegramMessenger/MTProxy is abandoned. This fork is the only actively maintained version.

Continued development depends on community support:

• GitHub Sponsors — sponsors' issues are prioritized
• TON: UQBOGq_b3eL63Qfkj6ykoBibK3zGJDQzLK91v2q-UCY7BPeb (send via @wallet in Telegram)
• USDT (TRC-20): TNVSj1QjZ5jqdaeshe7VCpXWo2S1n936Hj
• BTC: bc1qvxxldmanwggula7992uun5a2qxm65ej9h0unj7
• GetPageSpeed RPM packages — production-ready install with support

Issues without community interest may be closed after 60 days of inactivity.

[dvershinin]

Implemented in ced60b7.

Added .github/workflows/fuzz-scheduled.yml:

• Weekly cron (Sunday 03:00 UTC) + manual workflow_dispatch with configurable duration
• 30 minutes per target (vs 60s in PR CI)
• Corpus persistence via actions/cache — each run restores the latest corpus, grows it, saves it back. Coverage increases incrementally across weeks.
• Auto-files a GitHub issue with reproducer links on crash
• Crash/OOM/timeout artifacts uploaded for local replay

The existing PR fuzz workflow (fuzz.yml) got doc comments explaining how the two workflows complement each other.