feat: publish worker images for both Aurora services

[agustincelentano]

Why

The repository ships a placeholder Dockerfile:

FROM hashicorp/http-echo:1.0.0
CMD ["-text={\"status\":\"ok\",\"msg\":\"Hola mundo\"}", ...]

So no worker image is published for either service. Checked against public.ecr.aws: nothing exists under nullplatform/services/aurora-postgres-server, .../aurora-postgres-db, or any other spelling, while services/s3, services/dynamo-db and services/rds-postgres-* are all there.

With tofu-modules >= v7.x the agent runs a service from the image its package declares. Without one, Aurora cannot carry package_artifacts and stays on the legacy exec flow — the agent has to clone the repository and run scripts off disk. In the implementation where this surfaced it is the only entry left in the old model, next to six worker-orchestrated ones.

What

Mirrors services-postgresql-rds, which has the identical shape: one repository, two service paths, two images off the shared gRPC worker bridge.

File	Tooling
Dockerfile.aurora-postgres-server	aws-cli, gomplate, OpenTofu 1.10.10
Dockerfile.aurora-postgres-db	the same plus postgresql16-client

The db image needs the postgres client because aurora-postgres-db/scripts/aws/reassign_owned drives psql. OpenTofu is pinned at 1.10.10 rather than taken from apk, because the specs init an S3 backend with use_lockfile = true and alpine packages 1.7.x.

release.yml is replaced with the two-image chain from the RDS repository, so both artifacts are registered against the same tag and both land in the release notes.

Before the first release

Same configuration the RDS repository already carries: secrets AWS_ROLE_ARN_ECR_PUSH and ARTIFACT_NP_API_KEY, and variable NP_ARTIFACT_NRN. I could not verify those are present here.

Not verified

I did not build the images. The tooling list comes from reading what the workflows call (tofu in 30 files, aws in 23, psql in one under the db path), so a first build may surface a missing package.