chore: bump adminapi to 0.105.2 and postgres patches

[Crispy1975]

Summary

• ansible/vars.yml: adminapi_release 0.101.0 → 0.105.2
• postgres15: 15.14.1.132 → 15.14.1.133
• postgres17: 17.6.1.132 → 17.6.1.133
• postgresorioledb-17: 17.6.0.089-orioledb → 17.6.0.090-orioledb

All postgres bumps are build-counter increments within the same minor version, so per the convention established by 69188391 there are no README or schema-header changes needed.

Why now

The adminapi bump picks up the read-replica polling reliability work in supabase/supabase-admin-api#328 (dedicated /read-replica/recovered endpoint, setup-replica failure sentinel, concurrent-setup serialisation). This is what the platform worker PR (supabase/platform#33701) depends on, and what the supadev synthetic flow PR (supabase/supadev#371) is being mitigated against.

A companion salt repo PR also bumps adminapi to 0.105.2 to keep AMI and fleet config aligned.

Companion PRs

• supabase/supabase-admin-api#328 — admin-api: dedicated /read-replica/recovered endpoint + setup-replica failure sentinel + concurrent-setup serialisation
• supabase/platform#33701 — worker: switch read-replica polling to the new endpoint, fail-closed on out-of-date admin-api, defer ACTIVE_HEALTHY until replica is reachable via customer path
• supabase/supadev#371 — supadev: extend retries on the query_read_replica step to cover the post-ACTIVE_HEALTHY readiness gap

Test plan

• AMI build picks up adminapi 0.105.2 and the three postgres patches
• AMI integration test passes
• Verify in staging that admin-api on freshly-baked instances responds to GET /admin/v1/read-replica/recovered (it should — confirms the bumped binary is the right one)