refactor(exoscale): reduce ApplyChanges cyclomatic complexity - #6709

What does it do ?

Splits ExoscaleProvider.ApplyChanges into per-operation helpers (createRecords,
updateRecords, deleteRecords) plus two shared helpers: resolveZone for the
domain-filter and zone lookup that all three repeated, and findRecordID for the
name and type record match that update and delete duplicated verbatim.

This lowers the function's cyclomatic complexity from 26 to 6, with no new helper
above 7, leaving merge (9) as the package maximum. Output, ordering, error
propagation and the number of API calls are unchanged.

Part of #5419.

Motivation

ApplyChanges was the most complex function in the provider, and the update and
delete paths had drifted into near-identical copies of the same record lookup.
Separating them makes each operation reviewable on its own as the project lowers
its cyclop threshold.

Testing

• go test -race -count=1 ./provider/exoscale/ (20 tests)
• make test (full suite, all packages)
• golangci-lint run --timeout=10m ./provider/exoscale/... (0 issues)
• make licensecheck
• cyclop with max-complexity: 1 to read the exact numbers before and after
• The two tests added here cover the ListDNSDomainRecords error path and the
  no-matching-record path, neither of which was covered before. Both pass
  unmodified against the pre-refactor code, so they check that the behavior is
  the same rather than only that the new structure works.

AI assistance

Claude Code helped with the refactor and the two added tests. I reviewed the
result and checked the behavior myself with the test suite and linters.

More

• Yes, this PR title follows Conventional Commits
• Yes, I added unit tests
• Yes, I updated end user documentation accordingly