Flip to using DNSCluster for cluster discovery

[michaeljguarino]

This will give two things:

• eliminate libclusters use of the endpoints api that will be deprecated in kubernetes
• still provide cluster discovery in a way that aligns w/ k8s readiness probes (which is when it is added to the headless service)

Test Plan

e2e

Checklist

• If required, I have updated the Plural documentation accordingly.
• I have added tests to cover my changes.
• I have added a meaningful title and summary to convey the impact of this PR to a user.

Plural Flow: console

[greptile-apps]

Greptile Summary

This PR replaces libcluster (which uses the deprecated Kubernetes Endpoints API) with DNSCluster for Erlang cluster discovery, aligning node membership with Kubernetes readiness probes via a headless service. It also introduces base64 encoding for service_file content over GraphQL (extending this to stack_tarball as well), and cleans up an invalid JSON Schema type in plan.json.

Key changes:

• Cluster discovery: libcluster + Cluster.Strategy.Kubernetes removed; replaced by {DNSCluster, query: ...} configured via a DNS_CLUSTER_QUERY env var or a default of console-headless.<NAMESPACE>.
• Base64 encoding of file content: The :service_file GraphQL object now encodes content with Base.encode64/1, and the frontend decodeBase64 helper (using atob) decodes it before display. The same encoding now applies to stackTarball (previously returned the raw :stack_file type).
• Azure provider refactor: deployment_url/2 simplified to idiomatic Elixir pattern matching.
• JSON Schema fix: "type": "enum" corrected to "type": "string" in plan.json.

Confidence Score: 4/5

• Safe to merge with one logic issue to address: atob will garble non-ASCII UTF-8 file content in the browser.
• The cluster discovery migration is clean and straightforward, and the base64 encoding/decoding pipeline is correctly wired end-to-end. The one issue is the use of atob in decodeBase64, which doesn't handle multi-byte UTF-8 sequences correctly and would silently corrupt file content containing non-ASCII characters (e.g. comments or strings in non-English languages).
• assets/src/components/cd/services/service/ServiceComponentsFiles.tsx — the decodeBase64 helper needs to use TextDecoder instead of raw atob to handle UTF-8 content correctly.

Important Files Changed

Filename	Overview
assets/src/components/cd/services/service/ServiceComponentsFiles.tsx	Adds base64 decoding for service file content. The decodeBase64 helper uses atob, which doesn't correctly handle UTF-8 multi-byte sequences in file content.
lib/console/graphql/deployments/service.ex	Adds a custom resolver to the :service_file object that base64-encodes content before returning it over GraphQL, enabling safe transport of binary or complex text content.
lib/console/graphql/deployments/stack.ex	Changes stack_tarball resolver return type from :stack_file to :service_file, which will now base64-encode its content field. Test updated accordingly.
lib/console/application.ex	Replaces {Cluster.Supervisor, [topologies, ...]} with {DNSCluster, query: ...} for cluster discovery, removing the libcluster dependency entirely from the supervision tree.
rel/runtime.exs	Replaces libcluster topology config with a single dns_cluster_query config key, defaulting to console-headless.<NAMESPACE> with a fallback namespace of plrl-console.

Comments Outside Diff (1)

1. assets/src/components/cd/services/service/ServiceComponentsFiles.tsx, line 116-122 (link)

   atob does not correctly handle UTF-8 content

   atob decodes base64 to a binary string where each character represents one byte. For file content that contains multi-byte UTF-8 sequences (e.g. non-ASCII characters like accented letters, CJK characters, or emoji), this will produce garbled output since atob doesn't interpret the bytes as UTF-8.

   The backend uses Base.encode64 on raw bytes, so decoding should account for UTF-8:

   This ensures multi-byte UTF-8 sequences are correctly decoded from the raw binary data returned by atob.

_{Last reviewed commit: f4c9c64}

[michaeljguarino]

@greptileai