docs(copilot): require Secret payloads to be rendered as data

The inline-config Secret rendered its payload via `stringData`. That field is write-only: the API server
decodes it into `data` and does not persist `stringData` itself. As a result Helm's three-way merge could
never prune a key that was removed from the values, because the generated patch targets `stringData` while
the live object only has `data`. Stale sections therefore survived every upgrade and the init container kept
writing them back into `app.ini` on each start.

To prevent this class of bug from being reintroduced, document the rule explicitly: render Secret payloads as
base64 `data`, and assert Secret content in unit tests via `data.*` with `decodeBase64: true` plus a
`notExists` assertion for `stringData`.

See: https://gitea.com/gitea/helm-gitea/issues/1109
See: https://gitea.com/gitea/helm-gitea/pulls/1110

Co-authored-by: Copilot <copilot@github.com>

.github/copilot-instructions.md

@@ -43,6 +43,12 @@ image:
 - Use plural for `*.tpl` files, because they may contain functions for multiple resources of the same kind (e.g. `_services.tpl` for `httpService.yaml` or `sshService.yaml`, `_backendTLSPolicies.tpl` for `backendTLSPolicy.yaml`).
 - Use as prefix of YAML files the resource kind (e.g., `deployment.yaml` for `Deployment` resources). If there are multiple resources of the same kind, use a descriptive suffix (e.g., `deployment_metrics.yaml` for a `Deployment` related to metrics).
 - Short names like `pvc` for Persistent Volume Claims or `svc` for Services are not allowed in file names or key names.
+- Render `Secret` payloads as base64 `data` and never as `stringData`. The API server drops `stringData` and persists everything under `data`, so Helm's three-way merge cannot prune a key that was removed from the values — the stale key survives every upgrade. For example:
+
+```yaml
+data:
+  app.ini: {{ $config | b64enc }}
+```
 
 ### Unit Tests
 
@@ -52,6 +58,7 @@ image:
 - The `values.yaml` file must pass `yamllint`. The configuration is in `.yamllint.yaml`. Use `make yamllint` to run the linter.
 - The title of the unit test should clearly describe the scenario being tested. As title must be use a short sentence starting with a capital letter and ending without a period.
 - Each unit test must explicitly set a custom namespace and release name, rather than relying on defaults.
+- Assert `Secret` content via `data.*` with `decodeBase64: true` and add a `notExists` assertion for `stringData`.
 
 ### Commits & PRs