fix(infra): grant audit roles to current_user, not hardcoded portal (#60)

## Summary

The bootstrap SQL ended with:

```sql
GRANT audit_owner, audit_writer, audit_reader, audit_archiver TO portal;
```

— hard-coded `portal`. The compose file and `.env.example` both document `POSTGRES_USER` as overridable; any contributor who changed it hit:

```
ERROR: role "portal" does not exist
psql: /docker-entrypoint-initdb.d/01-init.sql:48: ERROR: role "portal" does not exist
```

Replace with `current_user`, which resolves at execution time to whoever is running the init SQL — i.e. the superuser Postgres just created from `POSTGRES_USER`, whatever its name.

## Recovery for anyone hit by the bug

The half-failed init left the postgres-data volume in a partially-initialised state. To reset:

```bash
cd infra/local
docker compose -f dev.compose.yml down -v   # wipes the volume
docker compose -f dev.compose.yml up -d     # bootstrap re-runs cleanly
```

## Test plan

- [ ] After merge + recovery: `docker compose ps` shows postgres healthy.
- [ ] `psql postgres://<user>:<pwd>@localhost:5432/portal_dev -c "\du"` lists the four `audit_*` roles, and your superuser is "Member of: {audit_owner, audit_writer, audit_reader, audit_archiver}".
- [ ] `psql ... -c "\dn"` shows the `audit` schema.
- [ ] Test with a non-default `POSTGRES_USER` value (set `POSTGRES_USER=apf_portal` in `.env`, wipe volume, re-up) — init still succeeds.

---------

Co-authored-by: Julien Gautier <julien.gautier@apf.asso.fr>
Reviewed-on: #60

infra/local/init/postgres/01-init.sql

@@ -41,8 +41,17 @@ ALTER DEFAULT PRIVILEGES FOR ROLE audit_owner IN SCHEMA audit
   GRANT DELETE ON TABLES TO audit_archiver;
 
 -- ---------------------------------------------------------------- Dev convenience
--- The default `portal` superuser bypasses these grants anyway, but
+-- The dev superuser (created by Postgres from POSTGRES_USER, default
--- granting the audit roles explicitly lets us test role-based access
+-- `portal` but overridable in infra/local/.env) bypasses these grants
--- with `SET ROLE audit_writer;` etc. from a psql session against the
+-- anyway, but granting the audit roles explicitly lets us test
--- dev DB. Production never grants all four to one user.
+-- role-based access with `SET ROLE audit_writer;` etc. from a psql
-GRANT audit_owner, audit_writer, audit_reader, audit_archiver TO portal;
+-- session against the dev DB.
+--
+-- `current_user` resolves at script execution time to whoever is
+-- running the init SQL — i.e. the superuser created from POSTGRES_USER,
+-- whatever its name happens to be. Hard-coding `portal` here was
+-- wrong: it broke any setup where the contributor changed
+-- POSTGRES_USER in their .env.
+--
+-- Production never grants all four roles to one user.
+GRANT audit_owner, audit_writer, audit_reader, audit_archiver TO current_user;