[Improvement] `init-postgresql` init container hardcodes secret name, incompatible with external PostgreSQL / CNPG

### What would you like to be improved?

### Description

The Helm chart's `init-postgresql` init container (in `templates/deployment.yaml`) hardcodes the Kubernetes secret name for the PostgreSQL password as `{{ .Release.Name }}-postgresql` (line 169). This assumes the Bitnami PostgreSQL subchart is always used and that the secret is always named according to the Bitnami convention.

This breaks compatibility when:

- Using an external PostgreSQL provider (e.g., CloudNativePG, CrunchyData, AWS RDS)

- Using the `cluster` subchart dependency with CNPG, where the secret name is user-defined (e.g., `gravitino-cnpg-secret`)

### Current Code

```yaml

env:

- name: POSTGRES_USER

value: {{ .Values.postgresql.auth.username }}

- name: GRAVITINO_DB

value: {{ .Values.postgresql.auth.database }}

- name: POSTGRES_PASSWORD

valueFrom:

secretKeyRef:

name: {{ .Release.Name }}-postgresql

key: password

```

`templates/deployment.yaml`, lines ~163-169

### Proposed Fix

Make the secret name configurable via a values field (e.g., `postgresql.existingSecretName`) while keeping backward compatibility:

**values.yaml** — Add a new field:

```yaml

postgresql:

enabled: false

auth:

username: gravitino

password: gravitino

database: gravitino

existingSecret: ""

existingSecretName: "" # <-- new: override for the init container secret name

```

**deployment.yaml** — Use the value with a fallback to the Bitnami default:

```yaml

- name: POSTGRES_PASSWORD

valueFrom:

secretKeyRef:

name: {{ default (printf "%s-postgresql" .Release.Name) .Values.postgresql.existingSecretName }}

key: password

```

**Behaviour:**

- When `postgresql.existingSecretName` is **not set** (default `""`): falls back to `{{ .Release.Name }}-postgresql` — fully backward compatible with Bitnami PostgreSQL.

- When `postgresql.existingSecretName` is **set** (e.g., `gravitino-cnpg-secret`): uses the user-defined secret name.

### Additional Context

The same pattern is already used in the `gravitino.conf` template for the JDBC host name (line 46 of `resources/config/gravitino.conf`):

```

jdbc:postgresql://{{ .Release.Name }}-cnpg-rw:5432/{{ .Values.postgresql.auth.database }}

```

This already assumes a CNPG-like naming convention (`-cnpg-rw`) for the host when PostgreSQL is enabled, so adding a configurable secret name would make the Helm chart consistently support both Bitnami and external/CNPG PostgreSQL setups.

### Environment

- Chart version: 1.3.0

- PostgreSQL backend: CloudNativePG (CNPG) 17

- Workaround currently: patch the deployment template to reference the correct secret name

### How should we improve?

_No response_

Start with values.yaml and templates/deployment.yaml, especially the init-postgresql container around lines 163–169. Add the configurable secret-name value with the documented default fallback, then verify rendered output for both an unset value and a user-defined external PostgreSQL secret.

Written by the indexing model from the issue text.