server.configuration together with server.existingConfigmap is silently discarded

[tada5hi]

Found while auditing PR #20. Pre-existing on master.

Problem

With both server.configuration and server.existingConfigmap set, the inline content exists nowhere in the release: templates/server/configmap-configuration.yaml is guarded by and .Values.server.configuration (not .Values.server.existingConfigmap), so no ConfigMap carries it, and both the server Deployment and the migration Job mount the operator's ConfigMap. Nothing in templates/validations.yaml mentions either key.

server.configuration is documented for file-only options, and in practice it is where db.ssl / socketPath / replication live. A user who sets both believes TLS-to-database is configured while the mounted file is the operator's.

Why it is inconsistent

The chart already fails loudly for the analogous pair two values over (validations.yaml, auth.existingSecret plus inline auth values: "remove them to avoid a false sense of configuration"), and for server.theme.files plus server.theme.existingConfigMap. This pair is the same shape and is the one that is silent.

PR #20 makes the precedence load-bearing in a second consumer, since the hook Job now resolves the same name through authup.server.configurationConfigMapName, so the silent drop spans both the server pod and the migration hook.

Suggested fix

A validations.yaml guard naming both keys, matching the wording of the auth and theme guards. Failing that, say "existing wins, the inline value is ignored" in the server.configuration doc comment, which today only says "Environment variables always win over file values".

Add the negative test to .agents/testing.md:

helm template t charts/authup --set 'server.configuration=logger: true' --set server.existingConfigmap=cm  # must FAIL