docs: state both purposes as co-equal, correct the review's premise

[incendiary]

The README led with dangling-CNAME detection and listed cloud matching as a bullet, which reads as though the first were the differentiator. It is the other way round: dangling-CNAME tooling is commodity, while identifying A records in claimable cloud space is what this tool adds.

README

The opening now states both jobs as co-equal and explains why the second is the less obvious one:

A dangling CNAME names a service, so its intent can be read straight from DNS. A bare A record cannot. If that address is a cloud IP the owner released, whoever allocates it next controls what is served for that hostname — and DNS gives no signal that this is the case.

It also states plainly that the tool produces targets and never claims them, which is why its output files are machine-readable records rather than prose reports.

REVIEW.md

That review was written against the same misreading. It assessed cloud attribution as a supporting attribute and recorded it ✅ Met — at a time when the parser discarded every field that made a match actionable, and the output said only resolved to aws IPs.

Rather than quietly rewrite the analysis, the mistaken premise is marked where it applies, the affected verdict is withdrawn, and a correction section records what the misframing caused the review to miss:

• region, service and border group discarded at parse time across all three providers;
• wildcard resolutions fed to the cloud matcher unmarked, so a wildcarded zone in cloud space buried real targets under the platform1s own addresses.

Both have since been fixed; the correction says so.

It is worth recording because it sharpens a lesson already in that document. The review was internally consistent, evidence-backed and thorough — while measuring against the wrong thing. Rigour applied to a wrong premise produces confident, well-supported, wrong conclusions. Tests being green did not catch it, and neither did the review process itself.

Run summary

Cloud matches sat as a quiet line beneath the takeover banner. If the two jobs are co-equal the summary should show it:

  [>] 8 CLOUD-HOSTED ADDRESS(ES) — candidate reclaim targets
  CSP matches — AWS: 8  GCP: 0  Azure: 0
    excluded (wildcard) :    4  (hosting platform addresses, not targets)
    by region and service:
         4  aws  GLOBAL  CLOUDFRONT
         4  aws  us-east-1  EC2

A run that finds none now says so, rather than staying silent — silence reads as "not checked".

Wildcard wording

It read not real hosts, which asserts non-existence DNS cannot establish: a live site and a fabricated name in the same wildcarded zone return identical answers. It now reads resolution proves nothing, which is what is actually true.

257 passed, ruff clean. Documentation and summary text only — no behavioural change to detection or matching.