[G-12] Validate examples and kubeconform in CI

## Summary
PR #95 (chart-testing lint and install) and PR #96 (helm-unittest) closed the core CI gap. Two follow-ups remain:

- [ ] Validate the values files under `examples/` against `values.schema.json`
- [ ] Run kubeconform against rendered manifests

### Details
Today `.github/workflows/lint-and-test.yaml` lints and installs only `charts/graylog/ci/ci-values.yaml`. Nothing in CI reads `examples/`, and kubeconform appears nowhere in the repo.

**Examples validation.** `helm template -f ` enforces the values schema, so a loop over the three example values files is enough. All of them pass today, so the step starts green, and it would have flagged the pre-fix AWS example from #121 (input entries missing the schema-required `name`).

**kubeconform.** Render the defaults, the ci values, and each example, then pipe through `kubeconform -strict` with `-kubernetes-version` set from the existing install-matrix versions (v1.32.11, v1.33.7, v1.34.3). Note kubeconform wants the version without the `v` prefix. The chart renders two CRs, `MongoDBCommunity` and the cert-manager `Issuer`, neither in kubeconform's default catalog. Add the datreeio CRDs-catalog as a second `-schema-location` (it carries both schemas) using the template `{{.Group}}/{{.ResourceKind}}_{{.ResourceAPIVersion}}.json`. The Issuer only renders when `ingress.enabled` and `ingress.config.tls.issuer.managed.enabled` are both set, which no current values file does, so add one extra render with those flags to cover it.

Both checks are static and need no cluster, so they fit the existing lint job or a small new job.

**Reference:** G-12 (Production Readiness Review)

### Impact
Example files are the first thing users copy, and nothing stops them from drifting. That is how #121 happened. kubeconform adds Kubernetes API validation of rendered manifests, which neither `helm template` nor the unit tests provide.

## Notes for maintainers
- The schema check is only as strong as the schema. `values.schema.json` sets no `additionalProperties: false` anywhere, so unknown and deprecated keys pass silently. Tightening it is a separate discussion (#63 touches the same file).
- Schema validation cannot see YAML duplicate keys. `examples/values-existing-secret-external-mongodb.yaml` declares `graylog:` twice (lines 43 and 77) and last-key-wins parsing silently drops the first block. A `yamllint` pass over `examples/` catches this class, and the duplicate itself deserves a fix.
- `examples/graylog-secret.yaml` and `examples/testing/test-gelf-input.yaml` are plain manifests, so kubeconform can check them directly in the same step.
- kubeconform needs network access to fetch schemas, or a pre-populated cache.

Start with .github/workflows/lint-and-test.yaml and inspect the values files under examples/ plus charts/graylog/ci/ci-values.yaml. Review the existing install-matrix Kubernetes versions and determine how rendered manifests, the CRDs-catalog schemas, and the TLS Issuer render should be covered. Done means CI validates all examples against values.schema.json and runs strict kubeconform checks for the specified renders and plain example manifests.

Written by the indexing model from the issue text.