doctor: sampled fallback findings can report the wrong source schema

[echemythia]

Deep doctor review found that Report::finding() only switches source_schema to s3tap.sample/1 for time-series rows.

Other rows can also be derived from s3tap.sample/1 when no connection closes during the capture:

• sampled baseline_rtt
• sampled retransmit-rate fallback
• sampled bdp_ceiling / recv_ceiling path fallback
• environment estimate when the RTT floor itself came from samples

Those findings can currently publish source_schema as operation/connection even when the value was derived from samples. That is a machine-output contract issue for fleet ingestion and downstream tooling.

Suggested direction:

• Track the source of the RTT floor and sampled fallback rows in Report or per row metadata.
• Emit source_schema: ["s3tap.sample/1"] when the finding value was derived only from samples.
• Add tests for sampled baseline_rtt, sampled retransmits and sampled path fallback rows.