qdrant: nothing in e2e exercises the trust-anchor path from the sentinel to tenantsecrets #3706

hack/e2e-chainsaw/qdrant/qdrant.yaml sets external: false and leaves tls unset. The chart resolves TLS from external when tls.enabled is absent, so TLS is off in every e2e run: the TenantProjection sentinel never renders, and no run walks the chain from the sentinel through the CA-extraction controller to the tenantsecrets read path.

postgres has the step to copy, verify-tenant-ca-projection in hack/e2e-chainsaw/postgres/chainsaw-test.yaml, and that step's own comment says why it exists: tenantresource is stamped by the lineage webhook, computed from the ApplicationDefinition's spec.secrets, and it is "true" only if the whole chain held, because nothing "short of a live cluster proves that link".

That step does not cover qdrant. postgres sources its CA from CNPG, which mints one regardless of the chart's TLS flag, which is why a plain fixture is enough there. qdrant is the first engine whose CA comes from cert-manager, and it only has one while TLS is on, so both the object the controller reads and the condition under which that object exists are different.

Turning it on is cheap. Flipping external to true would also allocate a LoadBalancer; adding tls: {enabled: true} to the fixture turns TLS on without one, after which the postgres step ports across.

What is unproven here is the benign direction, and that is worth saying plainly so this does not read as a security gap. A broken chain leaves the feature silently inert: the sentinel reports Ready=False and no tenant gets an anchor. The dangerous direction, a key-bearing Secret becoming tenant-readable, is pinned at the unit layer in cozystack/cozystack#3341 and verified by mutation against both the ResourceDefinition and the dashboard Role.

nats sits behind the same gap by a different route: hack/e2e-chainsaw/ carries 23 fixture directories and none of them is nats, so once cozystack/cozystack#3340 lands its leg of the contract will be unexercised too.