chore(deps): bump admin-mgr 0.38.0, admin-api 0.107.0, pg patch versions

[Crispy1975]

Summary

Bumps ansible/vars.yml so new AMIs built from this branch ship the host-lock work merged across admin-mgr, supabase-admin-api, and salt:

• adminmgr_release: 0.36.1 → 0.38.0
• adminapi_release: 0.105.2 → 0.107.0

Plus the three Postgres patch version bumps to match the latest released tags:

• postgresorioledb-17: 17.6.0.091-orioledb → 17.6.0.092-orioledb
• postgres17: 17.6.1.134 → 17.6.1.135
• postgres15: 15.14.1.134 → 15.14.1.135

Context

INDATA-722 introduced a host-level coordination lock at /var/run/admin-mgr/lock.json that admin-mgr writes for the duration of every long-running operation (restore, replica setup, walg toggle). admin-api and salt both consult the lock before any postgres lifecycle action so external restarts and reloads cannot interrupt a WAL-G restore mid-recovery.

For full design / contract see:

• supabase/admin-mgr README — The host lock model section
• supabase/supabase-admin-api README — Coordinating with admin-mgr (host lock) section
• supabase/admin-mgr#101, supabase/supabase-admin-api#332, supabase/salt#577

Rollout

• This PR: new AMIs picking up the lock-aware binaries directly.
• Existing instances: covered by the salt pillar bump in supabase/salt#577 (admin-mgr and admin-api versions pinned to match).

Test plan

• admin-mgr 0.38.0 manually validated end-to-end on a staging instance (11 lock-behaviour tests + a real restore cycle).
• supabase-admin-api 0.107.0 manually validated end-to-end via the test-admin-api script against a staging box (L1 dedup, L2 chokepoint, sync acquire, exit-75 mapping).
• Build the AMIs and smoke-test on a fresh staging project.
• Confirm the three pg patch bumps land cleanly through the existing CI matrix.