Helm chart for Kubernetes deployment

## Context

The Hyperswitch Recon team is deploying Invokr as a service and manages their
infrastructure as code. They need a Helm chart to install it onto their cluster.
Hyperswitch itself is expected to follow as a second consumer.

## What is needed

A chart covering Invokr's actual runtime shape — two workloads sharing one
PostgreSQL database:

- `invokr-api` — HTTP on :8080, also serves the dashboard
- `invokr-worker` — polls the database and delivers jobs; ops server on :9090,
no inbound application traffic

Plus schema migrations, Prometheus scrape configuration, Istio routing, and the
operational requirements a successful `helm install` does not by itself satisfy
(notably `pg_cron`, which must be enabled at the database server level, and the
org/workspace bootstrap).

## Decisions

- **Chart lives in this repo** under `helm/`, mirroring superposition's layout,
and is published as an OCI artifact so it can later be consumed the same way
`hyperswitch-helm` consumes superposition.
- **Images stay on GHCR.** `global.imageRegistry` redirects to a mirror in one
value, so an ECR mirror needs no chart change.
- **One install per consuming team.** Invokr's org/workspace model isolates
tenants of one product; it does not isolate two teams with independent
release calendars, worker pools and API credentials.

## Out of scope

Items the chart works around rather than fixes are tracked in
`helm/PENDING-CHANGES.md`, each naming the blocking work and the exact value to
change once it lands.

Start by reading the runtime requirements in the issue and the existing helm/ layout, then review helm/PENDING-CHANGES.md for known workarounds. The work is complete when the chart installs the API and worker, supports migrations, Prometheus scraping and Istio routing, and documents the pg_cron and org/workspace bootstrap requirements.

Written by the indexing model from the issue text.