docs(locations): cloud resource drift matching and the endpoint migration boundary

docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.md

@@ -81,6 +81,7 @@ Both create Locations on their identity hash and upsert their references, so the
 
 - It does **not** delete the original Endpoint or Endpoint_Status rows. They remain in the database to back the read-only legacy API. They are not used by the new UI or by imports after the feature is enabled.
 - It does **not** modify your Findings. The backfills only *read* the `component_*` and `file_path`/`line` fields; they add Locations and references alongside, leaving the Finding rows untouched.
+- It does **not** convert cloud resources into Cloud Resource Locations. Endpoints often recorded things that are not web addresses at all, such as container references and AWS ARNs. Every one of those migrates as a URL Location, the same as any other Endpoint. DefectDojo cannot reliably tell a resource identifier stuffed into a host field from a genuine hostname. Guessing wrong can change a Finding's identity. To model those resources properly, import the account through a cloud connector. The connector reads the provider's own resource identifier. It creates a Cloud Resource Location from that identifier.
 
 ## Endpoint API After Migration
 

docs/content/triage_findings/finding_deduplication/PRO__location_drift_matching.md

@@ -63,6 +63,14 @@ With tracking enabled, reimport matching happens in two stages:
 
 When the same vulnerable package appears in **several manifests**, each manifest's finding is tracked independently: a version bump in one lockfile never swallows the finding from another.
 
+### Cloud resource findings
+
+Cloud resources match on their identifier alone: the ARN, resource URI, or Azure resource ID the provider assigned. There is no fuzzy match here, and that is on purpose. A cloud provider assigns that identifier once, when it creates the resource, and never changes it. A bucket is not renamed into a different bucket. Instead, the provider deletes it and creates a new one. That new bucket is a genuinely different resource, so it is correctly a different finding.
+
+Region, service, tags, and display name can all change. The resource itself stays the same. None of these fields take part in the match. A relabelled instance is still the same instance, so it keeps its findings.
+
+Two findings on two different cloud resources are never duplicates of each other. If an earlier import merged them, they stay separate after the next import.
+
 ### Severity re-scores
 
 Security tools re-score severities as their rule engines evolve. With tracking enabled, a tool-reported severity change does **not** split a finding's identity: the finding matches, and its severity is updated from the scan, unless a person has re-triaged the severity by hand, in which case the human's value always wins (see below).