Stand up railiance01 receiver without founder bao kv put

Database leases come from ClusterSecretStore openbao-audit-core-database
(one extract, one lease). Senders are minted in-cluster. Secret mounts
use fsGroup 10001. Schema 0001-0004 applied after dropping the isolation
stub events table. /readyz reports custody_class=archive.

deploy/clustersecretstore.yaml

@@ -3,8 +3,8 @@
 #
 # Do not apply until Secret external-secrets/openbao-audit-core-eso-token exists
 # (scripts/openbao-eso-token-apply.sh). This store is KV-only: sender registry
-# lives at platform/workloads/audit-core/senders. Database leases are dynamic
-# and come from VaultDynamicSecret, not this store.
+# lives at platform/workloads/audit-core/senders. Database leases use the
+# sibling store openbao-audit-core-database (engine path, not KV).
 ---
 apiVersion: external-secrets.io/v1
 kind: ClusterSecretStore
@@ -29,3 +29,29 @@ spec:
   conditions:
     - namespaces:
         - audit-core
+---
+# Database engine, not KV. Same ESO token, different mount. Generators cannot
+# read a token Secret from another namespace, so leases come through this
+# store rather than VaultDynamicSecret.
+apiVersion: external-secrets.io/v1
+kind: ClusterSecretStore
+metadata:
+  name: openbao-audit-core-database
+  labels:
+    app.kubernetes.io/part-of: railiance-gitops
+    railiance-platform/component: external-secrets
+    app.kubernetes.io/name: audit-core
+spec:
+  provider:
+    vault:
+      server: http://openbao.openbao.svc:8200
+      path: database
+      version: v1
+      auth:
+        tokenSecretRef:
+          name: openbao-audit-core-eso-token
+          namespace: external-secrets
+          key: token
+  conditions:
+    - namespaces:
+        - audit-core