Fix #89: bump DB pool and add auth-path in-process caches

[ClaydeCode]

Summary

Closes #89

Parallel request bursts (e.g. Actual Budget loading ~30 SQLite migration files simultaneously) exhaust the 4-connection default pool in 2–3 in-flight forwardAuth calls. Remaining calls block for 30 s then 500. This PR applies all four fixes described in the issue:

• Pool size: AsyncConnectionPool(max_size=20, timeout=10) — headroom for realistic bursts; timeout=10 fails fast instead of stacking 30 s waits.
• Identity cache: _get_identity() in auth.py caches the default SafeIdentity in-process. Invalidated via a new on_identity_update signal fired from every identity-mutation path (identity.make_default, identity.enrich_identity_from_profile, PUT /protected/identities).
• App lookup cache: _find_app() caches the InstalledApp by name. Invalidated on the existing on_apps_update signal (already fires on install, uninstall, start, stop, shutdown).
• ensure_app_is_running DB read removed: docker_start_app now accepts an optional status param. ensure_app_is_running passes the cached app's status, skipping the extra get_by_name call.

Steady-state result: /internal/auth makes zero DB queries for the common path.

Recommended reading order

1. shard_core/database/connection.py — pool parameters
2. shard_core/util/signals.py — new on_identity_update signal
3. shard_core/service/identity.py + shard_core/web/protected/identities.py — signal fire sites
4. shard_core/web/internal/auth.py — caches + invalidation handlers
5. shard_core/service/app_tools.py — optional status param on docker_start_app
6. shard_core/service/app_lifecycle.py — pass cached status

Test plan

• Hard-refresh Actual Budget (or any private-access app) after clearing browser cache — all ~30 parallel asset requests should return 200 without any 500s
• Install/uninstall an app, verify subsequent auth requests still resolve correctly (cache invalidated)
• Update default identity via PUT /protected/identities, verify headers still reflect new identity on next auth request
• GET /internal/auth for unknown app still returns 404
• Existing test suite passes (requires Docker+Postgres environment)

🤖 Generated with Claude Code

[ClaydeCode]

Pushed fixes for both review comments.

Signal layer (signals.py:9)

You're right that having the signal fire from two layers (service and web) was inconsistent. I've added update_identity(id, update_data) to service/identity.py — it does the DB write and fires on_identity_update. The web handler (identities.py:put_identity) now calls this instead of touching the DB directly. enrich_identity_from_profile likewise uses update_identity now. Every on_identity_update fire is in the service layer; the DB layer stays signal-free.

Stale cache / throttle (app_lifecycle.py:33)

Reverted the status parameter from docker_start_app. The function always reads fresh status from DB, so there is no "cache says RUNNING but container is down" discrepancy — both the cache and DB would agree, since they're only out of sync during external Docker events, and in those cases docker_start_app still calls docker-compose up -d (RUNNING is intentionally in the allowed-start list to handle crashed containers).

The throttle is still needed and I've kept it: it prevents docker-compose from being spawned on every auth request even though the DB read is now the only per-5s cost. Without it, 30 parallel migration fetches would spawn 30 concurrent docker-compose up -d subprocesses. The cache's job is to eliminate the two _find_app/_get_identity DB connections per auth call; docker_start_app's single throttled read is an acceptable residual.