feat: add LinkedDatabase CRD

[tkelkermans]

Summary

• Add a namespaced LinkedDatabase CRD for creating logical PostgreSQL databases on an existing NDB database instance.
• Map reconciliation to POST /databases/{sourceDatabaseId}/linked-databases with body {"databases":[{"databaseName":"<name>"}]}.
• Support identifying the source instance by spec.sourceDatabaseId or by spec.sourceDatabaseName resolved from NDBServer status.
• Check existing linked databases before issuing create, so an already-present linked database is adopted into CR status instead of posted again.
• Add generated CRD/RBAC, Helm CRD/RBAC, API helpers, controller tests, and README documentation.

Scope notes

• This PR implements the create/observe flow only. Deleting a LinkedDatabase CR does not delete the linked database from NDB.

Verification

• make test
• bin/kustomize build config/default >/tmp/ndb-default.yaml
• helm lint deploy/helm

[manavrajvanshi]

Hi @tkelkermans

Is there any specific use-case that would require a separate linked-database CRD and controller specifically? Have you considered moving the linked-databases within the Databases custom resource instead? Were there any challenges in that approach?

[tkelkermans]

Thanks @manavrajvanshi. The driving use case is a separation of duties: infrastructure team provisions the PostgreSQL instances (via Database / NDB), and developers add logical databases into those already-existing instances without touching the instance config or re-provisioning anything.
That's why a separate resource rather than folding it into Database: Database.spec today is provisioning-only — databaseInstance is a full instance definition and clone creates a new one. There's no way to express "attach to an instance that already exists." Embedding linked DBs in Database would force developers to author/own a full Database CR for an instance they didn't create (risking drift or accidental re-provisioning), or require adding an "attach to existing instance" mode to Database that conflicts with its current create-a-new-instance semantics.
LinkedDatabase keeps the same admin/developer boundary the operator already uses for NDBServer (cluster-scoped, infra-owned) vs Database (namespaced, developer-owned): the instance is provisioned by infra, and developers reference it by sourceDatabaseId/sourceDatabaseName from their own namespace to add a logical DB. It also gives each linked DB its own status/operation tracking instead of pushing that onto the parent instance's reconcile loop.
The main challenge with the embedded approach was exactly that: the parent instance is out-of-band (not necessarily managed by a Database CR at all), so a list on Database.spec can't represent it. Happy to discuss further if you see a cleaner fit.