Distinguish camera flash failure from printer-side LAN streaming crash

[phryneas]

Summary

Put the two different camera-feed failure modes at the very start of the README, before identification or hardware work: the camera-module flash/configuration failure repaired here, and the printer-side ai_camera streaming crash that these tools do not fix. A missing feed or failed stream-identification request is not treated as proof of a failed camera.

Add one self-contained research note, docs/PRINTER-LAN-STREAM-FAILURE.md, linked from the README and the existing USB research evidence. It records the exact affected June build, retained HTTP client threads, 370 eight-MiB stack reservations versus nine live threads, recovered std::system_error(generic:11 / EAGAIN) and SIGABRT path, evidence limits, and the separate LAN-paused state after a manual restart. It includes input fingerprints and audit anchors without publishing binaries, core memory, or private logs.

Mention viridivn/ai_camera as an optional replacement for rooted CC2 owners or those considering root access. Attribute the supplied owner's approximately one-week successful-use report and preserve upstream's caveats: LAN-only testing, removed AI functionality, further stress testing needed, and incomplete firmware coverage. This is not a guarantee or a new installation feature in cc2camera.

Also clarify the replacement-webcam check: rebooting restarts the streaming service, so a substitute webcam working after reboot alone cannot prove the stock camera is faulty. Hardware comparisons and printer-service changes must not interrupt a print.

Scope and validation

• Documentation only: three Markdown files; no CLI, supported-device, validation, or repair-command changes.
• Read and followed the repository's AGENTS.md.
• Checked changed Markdown links/anchors, git diff --check, and preservation of existing README command blocks.
• Verified the edited file contents against Git blob hashes before committing.
• Re-ran both offline core/exception verifiers successfully against the privately supplied exact artifacts; the ARM binaries were not executed.
• No firmware, binaries, core slices, raw private logs, or user network identifiers were added.
• The complete repository test suite was not run locally: direct Git cloning was unavailable, so the documentation was prepared from hash-verified files retrieved through the GitHub connector. No additional hardware testing or replacement-service stress testing was performed.