CI: install-test the example values files

Split out from #127: that issue covers authoring the example files (examples/nebari-values.yaml, examples/standalone-values.yaml if applicable, examples/argocd-application.yaml). This one covers making CI prove they actually work, so the examples cannot rot.

Today CI only lints and templates with the NebariApp disabled and never touches any example values:

https://github.com/nebari-dev/nebari-data-science-pack/blob/bcf0eb7a8c5b07dce58ce3053c2a7ea729e562f3/.github/workflows/lint.yaml#L24-L27

Acceptance criteria

• helm template renders the chart with each file under examples/ (hostname placeholder substituted) and the output passes the manifest schema validation from #124
• A kind-based CI job runs helm install with the example values (standalone example, or the nebari example with nebariapp.enabled=false if #122 lands on standalone-supported: no) and waits for the hub to become Ready
• Core features verified working on that install, not just "pods up": user login, server spawn reaches a running JupyterLab, shared storage mounted and group-writable, jhub-apps landing page serves. Reuse the existing e2e suite against the example-values deployment rather than writing a parallel one
• The ArgoCD Application example is schema-validated as part of the same job
• Job runs on push/PR alongside the existing lint workflow

Related

• #127 (authoring the examples)
• #124 (kubeconform / schema validation step this builds on)
• #122 (standalone-supported decision gates which example gets the install test)

Start with .github/workflows/lint.yaml and the existing e2e suite, then inspect the example files under examples/ and the schema-validation step from #124. Add a push/PR kind-based job that templates and schema-validates each example, installs a supported example, and reuses the e2e checks. Done means the hub becomes Ready and login, server spawn, shared storage, jhub-apps, and the ArgoCD Application example are verified.