fix: stop server-owned cache workers during shutdown

[Optic00]

Server shutdown leaves BigCache cleanup workers running. With the session validation cache disabled, two successive start/stop cycles left four additional workers each. Enabling session caching adds another cache that also lacked shutdown ownership.

The HTTP server now retains and closes its permission, session, API-token, SCIM-token and item-hierarchy caches. Their Close methods tolerate repeated calls and disabled caches; they do not close the shared database. Partial startup failure also closes these caches and signals already-started background loops to stop. Unrelated cache instances are left alone.

Regression tests are on the separate core-tests branch. They exercise real server lifecycles with session caching enabled and disabled, repeated shutdown, an unrelated cache, and a failed startup after cache allocation. Additional tests cover concurrent repeated Close calls and absent caches. The original four-worker leak was reproduced before the fix.

SQLite and PostgreSQL shutdown regressions pass with the race detector, including enabled/disabled session caches. The startup-failure case is SQLite-only. The full internal/auth, internal/services and internal/server package runs passed, as did the quick suite (five Go packages, 14 frontend files/123 tests). go vet and the configured linter passed for the changed packages.

This does not establish the cause of an earlier PostgreSQL suite timeout. Closed caches remain referenced by the diagnostics registry until replaced; this fix stops their workers, not all retained cache memory. No authentication rules, TTLs or cache budgets change.