Stop documenting the recovery API that 1.6.0 deleted

Disc::sweep, Disc::patch, Disc::copy, SweepOptions and PatchOptions have
zero occurrences in src/ — recovery moved to freemkv-engine — but they were
still documented in 30 places across README.md, TROUBLESHOOTING.md, six
files under docs/, seven src/ doc comments and a Cargo.toml comment.
README.md is the crate's GitHub front page and carried a full multi-pass
code example that cannot compile.

Two of the src/ references were intra-doc LINKS to deleted items
([`disc::Disc::copy`], [`disc::Disc::patch`] in scsi/mod.rs). They produced
no warning on a normal `cargo doc` only because they sit on pub(crate)
items; `--document-private-items` reports both, and they are gone now.

The README example is deleted rather than rewritten against the engine's
API: libfreemkv documenting a downstream crate's API on its own front page
is the drift that produced this, and it cannot even depend on it. The src/
references become plain code spans naming freemkv_engine::recovery::* —
deliberately not links, for the same reason.

docs/rip-recovery.md was 202 lines about relocated code. It now documents
only what this crate owns — Drive::read, SenseFamily, DiscStream's adaptive
batch halving — plus the read-path design constraints, which belong with the
code that enforces them, and points at freemkv-engine/src/recovery/ for the
strategy. api-design.md's module tree is regenerated from the real src/disc/
and src/drive/ layouts instead of hand-patched; it had listed sweep.rs,
patch.rs, mapfile.rs and read_error.rs, none of which exist.

Three stale facts surfaced while rewriting and are corrected: the read
timeouts are 10 s / 60 s, not the documented 1.5 s / 30 s; Drive::reset and
SgIoTransport::reset no longer exist at all, so "no SCSI reset from any read
path" is now stated as the stronger fact it has become; and verify_title,
listed as a progress-emitting operation, was removed entirely.

CHANGELOG.md keeps its references — those are the historical record of the
releases that shipped the API.

src/drive/mod.rs

@@ -715,19 +715,19 @@ impl Drive {
     /// SCSI reset.
     ///
     /// `recovery=true` uses [`crate::scsi::READ_RECOVERY_TIMEOUT_MS`] (60 s,
-    /// matches sg_dd) for the `Disc::patch` pass; `recovery=false` uses
-    /// [`crate::scsi::READ_TIMEOUT_MS`] (10 s) for `Disc::copy`'s fast
+    /// matches sg_dd) for the `freemkv_engine::recovery::patch` pass; `recovery=false` uses
+    /// [`crate::scsi::READ_TIMEOUT_MS`] (10 s) for `freemkv_engine::recovery::copy`'s fast
     /// skip-forward sweep. Both budgets are generous enough that the drive
     /// can finish ECC recovery on a marginal sector — pre-0.13.21 this was
     /// 1.5 s on the fast path which forced the kernel mid-layer to time
     /// out and escalate while we waited anyway. On any failure returns
-    /// `Err(DiscRead)` immediately; orchestration (`Disc::patch` multi-pass,
+    /// `Err(DiscRead)` immediately; orchestration (`freemkv_engine::recovery::patch` multi-pass,
     /// `DiscStream` adaptive batch halving) handles retry policy.
     ///
     /// Inline retry phases (5× gentle + reset+reopen + 5× more) were
     /// removed in 0.13.6: on some USB-SATA bridges the inline reset wedged
     /// drive firmware without ever recovering a sector. The remaining
-    /// recovery layers (Disc::patch multi-pass, DiscStream batch halving)
+    /// recovery layers (freemkv_engine::recovery::patch multi-pass, DiscStream batch halving)
     /// do not touch the wedge-prone reset path.
     pub fn read(&mut self, lba: u32, count: u16, buf: &mut [u8], recovery: bool) -> Result<usize> {
         // Bulk path: FUA off (the drive cache IS the streaming throughput).