refactor: decouple secret handling from Kubernetes Secret and label concepts

[choufraise]

Problem

Secret handling in the codebase is still heavily shaped by Kubernetes Secret concepts.

Today we rely on an outbound SecretClient abstraction that is nominally generic, but in practice it is tightly coupled to Kubernetes-specific behavior:

• Kubernetes Secret naming
• Kubernetes labels and label values
• Kubernetes-oriented lookup and delete patterns
• adapter k8s constants reused across core and controller code

This creates two related problems:

1. the abstraction is misleading

   • SecretClient sounds generic, but it really assumes a Kubernetes Secret backend and Kubernetes-specific metadata conventions

2. the dependency direction is wrong

   • core and controller code still depend on Kubernetes-oriented constants and semantics, which conflicts with the hexagonal architecture direction

This is closely related to #185, but focuses specifically on secret handling and the SecretClient abstraction.

Why this matters

In the current architecture, outbound ports should describe the needs of the core, not leak details from a specific adapter implementation.

If the core depends on concepts like Kubernetes labels, secret-type labels, and Kubernetes-style secret lookup conventions, then the port is not really abstract. It is just Kubernetes wearing a generic name.

We should be able to express secret-related behavior in terms of the domain/application needs, not in terms of Kubernetes resource mechanics.

Proposal

Rework the current outbound.SecretClient into more specific outbound port(s) that describe what the core actually needs.

The new abstractions should:

• be explicit about the business purpose of the secret interaction
• avoid Kubernetes terminology such as Secret, labels, and label values where possible
• avoid exposing adapter-specific lookup mechanisms to core and controller code
• make it possible for the Kubernetes adapter to implement the port using labels internally without leaking that detail across the boundary

Examples of the kind of direction this issue should explore:

• separate ports for account key storage, user credential storage, or cluster credential lookup
• domain-oriented lookup methods instead of generic label-based queries
• moving Kubernetes label constants fully into the Kubernetes adapter layer
• removing Kubernetes-specific metadata assumptions from the core-facing port API

Acceptance criteria

• core code no longer depends on Kubernetes Secret concepts through a misleadingly generic port
• secret-related outbound ports are renamed or redesigned to reflect domain/application intent
• Kubernetes-specific labels and label values are kept inside the Kubernetes adapter layer
• controller/core code no longer needs to understand or reference Kubernetes secret label conventions
• the resulting abstractions align with the hexagonal architecture direction and complement remove core/controller dependencies on adapter k8s package #185

Notes

This is an architectural cleanup issue. No intended behavior change.

[choufraise]

In #318 we continued relying on both the Account Root- & Sign secret to exist to focus the fix to the deletion issue. The code is commented with a // TODO: [#196] Only lookup account root secret.in core/account.go. This should also be considered when fixing this issue.