feat(dns): add Policy, ResponsePolicy and ResponsePolicyRule

[naxty]

Completes Cloud DNS, which had only ManagedZone. Stacked on #168.

Case	Result
dns-policy	crud 8/8, discovery 4/4
dns-response-policy	crud 8/8, discovery 4/4
dns-response-policy-rule	crud 8/8, discovery 4/4

All three green in one clean sweep (24–29 seconds per case — DNS is by far the
cheapest service to test in this plugin).

Verified through debug-conformance.yml, not locally. The local
service-account key is 403 on every DNS call, while CI's identity creates DNS
zones routinely for the existing managed-zone case. That is why the workflow
c14ab91 added is the verification path for this batch.

Notes for review

Cloud DNS does not agree with itself about what an identifier is called. A
managed zone and a policy use name, a response policy uses
responsePolicyName, a rule uses ruleName. A forma declares name for all of
them and paired transformers translate at the API boundary, so three spellings
stay inside the plugin rather than leaking into every forma. The native-ID
extractor accepts all three, because a list item is the only place an id appears
during discovery.

The rule collection is rules in the URL but responsePolicyRules in a list
response — handled with ListItemsKey.

Three bugs the first CI runs found, all in discovery:

1. base.extractNativeIDFromItem reads itemMap["name"] and gives up when
   it is empty, before ever calling the API's own native-ID extractor. So any
   GCP collection whose items do not use name is invisible to the generic
   List, no matter what the plugin supports. Worked around with a small custom
   List here rather than changing base under a stack of branches — but it is
   worth fixing properly.
2. Cloud DNS stamps every local-data record with a kind, which failed Verify,
   Sync and Update as a property no forma wrote.
3. A rule's read carries nothing naming its response policy — that lives
   only in the URL — so discovered rules arrived without responsePolicy, a
   required createOnly property, and were dropped. Found on every pass,
   persisted on none. TransformContext carries no parent, so this had to be a
   Read override rather than a response transformer.

What I could not verify

• ResourceRecordSet is deliberately absent. Its delete path takes a
  two-segment {name}/{type} identifier unlike anything else in this plugin;
  bolting that onto a batch whose other three are conventional would risk the
  whole PR on one awkward type. It is the last gap in the service.

---

Correction (2026-08-28): this body reported CRUD as 8/8. That was wrong. The
Replace step reports [~] — skipped, not passed: the harness only runs it when a
testdata/<case>-replace.pkl fixture exists, and no case in this repo has one (0 of
118). Read every 8/8 above as 7 passed, Replace not exercised. The same applies
to every GCP resource already on main — the Replace path has never been covered
here. Nothing in this PR regressed.