fix(setup): respect PUID/PGID + look up www-data from /etc/passwd

[sylvesterdamgaard]

Problem

internal/setup/permissions.go hardcoded uid/gid 82 in setupLaravel, setupSymfony, and setupWordPress:

```go
// Set ownership (www-data UID/GID typically 82 on Alpine, 33 on Debian)
pm.chownRecursive(filepath.Join(pm.workdir, "storage"), 82, 82)
pm.chownRecursive(filepath.Join(pm.workdir, "bootstrap", "cache"), 82, 82)
```

On Debian-based images (`php-fpm-nginx:8.5-bookworm` and friends) `www-data` is uid 33, so the chown left storage/ at uid 82 (UNKNOWN user) while the fpm worker actually runs as uid 33 — a mismatch that breaks every framework directory the binary tries to "fix".

Concrete symptom: Laravel view cache writes fail, `tempnam` falls back to `/tmp`, the debug error renderer escalates the resulting E_NOTICE → ErrorException → 500 on every route. Setting `PUID=33 PGID=33` in the deployment env had no effect because the Go binary ignored those vars.

Fix

New `resolveAppUser` helper picks the uid/gid in this order:

1. `PUID` / `PGID` env vars — explicit operator override. Both must be valid non-negative integers or the override is ignored.
2. `/etc/passwd` lookup of `www-data` — handles Debian (33) and Alpine (82) without hardcoding either, so the same binary produces correct ownership in both baseimages.
3. Fallback to the previous `82, 82` Alpine-convention default.

The chosen path is logged so an operator can see which one resolved:

```
INFO Setting up permissions framework=laravel
INFO App user from /etc/passwd lookup user=www-data uid=33 gid=33
```

Tests

• `TestReadPuidPgidEnv` covers the env parser including edge cases (one set, the other unset; non-numeric; negative; uid 0 valid).
• `TestResolveAppUser_PUIDOverridesPasswdLookup` confirms the env override wins over the passwd lookup.
• `TestResolveAppUser_FallsBackWhenLookupFails` confirms the Alpine-convention fallback only kicks in when both prior paths miss.

`go test ./internal/setup/...` passes.

Test plan

• Unit tests pass (`go test ./internal/setup/...`)
• Re-tag the affected baseimages (`php-fpm-nginx:*-bookworm`) and verify a Laravel pod starts with `storage/` + `bootstrap/cache/` owned by uid 33 without any postStart hook