feat(workload): port K8s resource management and membership foundations (8/14)

[marceloneppel]

Issue

Part of the final charm->library migration (follows the VM stack, PRs #355-#361): the K8s charm still owns its K8s-API resource management and cluster-membership foundations. Final state: no logic charm-side.

Solution

• K8sManager (managers/k8s.py) gains the client seam: create_services, patch_pod_labels, check_headless_service, reparent_services_on_stop, cleanup_old_cluster_resources. Port of the K8s charm's section A.
• ClusterMembershipManager K8s branches: hosts = pod names; add_members_k8s/add_cluster_member_k8s as separate _k8s-suffixed methods (the VM variants keep the base names); DNS/service-name builders (get_hostname_from_member, get_hostname_by_unit, build_service_name) live here — the K8s workload lacks app/namespace, so the plan's workload/k8s.py destination was deviated (disclosed).
• PostgreSQLApplication.add/remove_endpoint + endpoints writer.
• Tests: tests/unit/test_k8s_resources.py (12 cases; real lightkube model objects; msgspec-valid ApiError).

Checklist

• I have added or updated any relevant documentation.
• I have cleaned any remaining cloud resources from my accounts.