docs(srm): update README to clarify SRM image requirements and configuration details

| PostgreSQL | `oop` | Shared instance; one database and role per component |

| NATS | `oop` | Message bus between OEG, SRM and FM; JetStream on, used only by FM |

| AI2 MCP | `oop` | MCP server exposing CAMARA-compliant tools |

| AI2 AI Agent | `oop` | Natural language interface backed by Groq |

| AI2 AI Agent | `oop` | Natural language interface backed by Groq, with a Redis for its session memory |

| Portal | `oop` | Developer portal: web UI and its backend (login, OEG and AI2 proxy, API clients) |

| Data Lab | `oop` | Dataspace metadata catalogue: piveau hub and search, Virtuoso, Elasticsearch, the Data Lab UI and API. Off by default, see [Data Lab](#data-lab) |

Each of OEG, SRM, Federation Manager and AI2 has its own chart README with all its values:

Each of OEG, SRM, Federation Manager, AI2, Portal and Keycloak has its own chart README with all its values:

[OEG](oop-platform-chart/charts/oeg/README.md), [SRM](oop-platform-chart/charts/srm/README.md),

[Federation Manager](oop-platform-chart/charts/federation-manager/README.md),

[AI2](oop-platform-chart/charts/ai2/README.md).

[AI2](oop-platform-chart/charts/ai2/README.md), [Portal](oop-platform-chart/charts/portal/README.md),

[Keycloak](oop-platform-chart/charts/keycloak/README.md).

### Architecture

- Realm roles in `oop`: `app-provider` (developers; given to every new user, including

  self-registered ones), `operator` (runs the platform) and `platform-admin` (manages users). None

  implies another; one person can hold several.

- Client `oop-portal-admin` is the portal backend's user-management account: its service account holds

  only `realm-management` `manage-users`, `view-users`, `query-users` and `view-realm`, and its secret is

  `keycloak-credentials` → `oop-portal-admin-client-secret`. People never get Keycloak admin rights

  through the portal; the portal checks `platform-admin` on its user pages.

- Client `oop-portal-admin` is the user-management account for the portal's user pages (ADR-0048): its

  service account holds only `realm-management` `manage-users`, `view-users`, `query-users` and

  `view-realm`, and its secret is `keycloak-credentials` → `oop-portal-admin-client-secret`. The portal

  has no user pages yet and does not use it; until it does, users are managed in Keycloak's admin console.

- Keycloak's public URL is `http://<global.publicHost>:30081` (kind sets `publicHost: localhost`; other

  clusters detect it at install). Every token carries `iss=<public URL>/realms/<realm>`, even when a pod

  fetches it from `http://keycloak:8080`. OEG and Federation Manager expect that public issuer, built

  password?" stays on the login page, but its texts (`keycloak.realms.oop.forgotPassword`) tell users to

  ask a platform administrator. An admin resets the password in the admin console: Users → the user →

  Credentials → Reset password, marked *Temporary* so the user picks a new one at the next login.

  Logged-in users change their own password through the portal (`kc_action=UPDATE_PASSWORD`).

  Logged-in users change their own password in Keycloak's account console (`<Keycloak URL>/realms/oop/account`).

- Every install creates a first `platform-admin` user, `oop-admin`, so someone can log in and manage

  users on a cluster without sample users. Its password is generated into `keycloak-credentials` →

  `initial-admin-password` and is temporary: the first login asks for a new password, and for an email

On kind, SRM gets a ready-made setup from `environments/kind/values.yaml`: one Kubernetes control

path `k8s-local` that deploys into namespace `oop-apps` of the kind cluster itself, and a matching

bootstrap topology with one zone.

bootstrap topology with one zone. Its `endpoint_host` is a placeholder, `<IP>`: replace it with the

address apps' NodePorts are reached on, usually the kind node's

(`docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' oop-cluster-control-plane`).

SRM reports it in the endpoints of deployed apps.

---

## Release compatibility

Use the SRM single-bootstrap change with SDK 2.0.0rc4 and its matching image.

The release integration baseline is SRM `develop` at

[`8fdb12a5`](https://labs.etsi.org/rep/oop/code/service-resource-manager/-/commit/8fdb12a544d8fd2e97744be819c3181f061a4548).

Its Dockerfile already installs Helm 3.18.6 and uses the SDK package index. The new

candidate package/image must be available before deployment. Upgrade or roll

back SDK, SRM, chart and configuration together.

Use the SRM image built with the SDK version SRM's `pyproject.toml` pins (2.0.0rc4). The image

installs Helm 3.18.6. Upgrade or roll back SDK, SRM, chart and configuration together.

## What SRM needs

| `nats.drainTimeout` | int | `30` | Seconds to drain NATS on shutdown |

| `federationManager.url` | string | `""` | Federation Manager internal API address; empty = `http://<global.federationManager.host>:<port>` (`http://federation-manager-internal:8083`) |

| `federationManager.timeout` | number | `5` | Seconds per Federation Manager call |

| `instancesMonitorInterval` | number | `30` | Seconds between probes of capability instances' runtime state (`INSTANCES_MONITOR_INTERVAL`) |

| `zoneProviderName` | string | `""` | Provider name SRM reports for its zones; empty = SRM's default (`oop-provider`) |

| `controlPaths` | list | `[]` | Retired; nonempty input fails with a migration error |

| `controlPathCredentials` | list | `[]` | Generated references to existing credential Secret mounts |

## One bootstrap for control paths and topology

Put the complete SDK bootstrap in `topology`. SRM loads one

revision and derives discovery and its execution registry from it. Remove the

old independent `controlPaths` list. Instance identity is derived from each

revision and derives discovery and its execution registry from it; the

`controlPaths` list is retired. Instance identity is derived from each

`control_paths[].ref`; do not repeat it in infrastructure configuration.

For the cluster SRM runs in:

A disk-backed `emptyDir` at `/var/run/openop-tfsdk` holds private SDK execution

files. This chart supports that runtime directory. Credential-provider plugins,

ambient connection defaults and independent `api_server` overrides are

unsupported by the paired SDK candidate. `endpoint_host`, if needed, addresses

unsupported by the SDK. `endpoint_host`, if needed, addresses

the deployed application rather than the Kubernetes API server.

Bootstrap is declared topology, not backend health. SRM keeps create-missing

seeding: existing DB entries are not updated or deleted by this change.

seeding: existing DB entries are not updated or deleted.

Changing `topology` restarts the Pod through its existing checksum annotation.

Offline chart verification: