chore(openhands): remove no-op values file keys

[jlav]

Description

An audit of the values files for no-op keys (keys nothing consumes, prompted by an earlier typo where a postgres setting everyone believed was applied actually wasn't) turned up a batch in the openhands chart tree. The values file doubles as documentation of the available config options, so keys that do nothing are misleading. This removes them:

• Umbrella: the vertexAI block (superseded by the vertex wiring in openhands-secrets / litellm-env-secrets), crdCheck.location (the crd-check hook reads every other key in that block), integrations-hub.service.baseUrl, integrations-hub.database.existingSecret, and runtime-api.externalDatabase (the subchart has no externalDatabase handling; its external DB config is the database block).
• runtime-api: top-level nodeSelector/tolerations/affinity (the deployment never wires them; only kvm.nodeSelector/kvm.tolerations exist), kvm.resourceName (the device plugin hardcodes ^kvm$; the comment claimed otherwise), the unused parts of the postgresql block, the externalDatabase block, and the helm-release-pruner block (not a dependency, referenced nowhere).
• automation and integrations-hub: the minio and postgresql blocks read like subchart pass-through config, but neither chart declares any dependency, so only the handful of keys their own templates read are live (minio.enabled/external/svcaccts[0], postgresql.enabled). Everything else is removed and the comments now describe what the flags actually do.
• integrations-hub: service.baseUrl (templates read openhands.baseUrl), database.existingSecret (no secret-creating template exists), database.poolSize/maxOverflow (never emitted into env).
• replicated/openhands.yaml: the KOTS vertex block that set the dead umbrella vertexAI values. VERTEXAI_PROJECT/VERTEXAI_LOCATION already reach litellm through the openhands-secrets chart.

Helm Chart Checklist

• I have tested the chart upgrade path from the previous version
• I have verified backwards compatibility with existing values.yaml configurations
• I have updated the chart's README.md if there are any breaking changes or new required values

Additional Notes

I verified this is a pure no-op: helm template output is byte-identical to main, both with defaults and with automation, integrations-hub, plugin-directory, agent-canvas, and the runtime-api kvm plugin force-enabled. Consumers still setting any of the removed keys keep working; the keys were ignored before and remain ignored.

The one judgement call: I removed dead keys rather than wiring them up. If we actually want runtime-api pod-level nodeSelector/tolerations/affinity support, that should be a deliberate feature change, and I'd rather not sneak it into a cleanup.