Fix initializeCache() not clearing in-memory perms collection on tenant/cache switch

[drbyte]

Fixes #2964

Problem:

initializeCache() re-resolves the cache store and config but leaves $this->permissions untouched. Since PermissionRegistrar is a singleton and loadPermissions() short-circuits when that collection is already populated:

if ($this->permissions) {
    return;
}

any process that switches cache context mid-lifetime (multi-tenant apps switching tenants, queue workers, artisan commands looping over tenants, Octane workers) keeps serving the previous tenant's permissions after calling initializeCache() — exactly the call our own docs recommend for this scenario. Because hasDirectPermission() matches by primary key, and each tenant DB has independent auto-increment IDs, a leftover collection doesn't just serve stale data — it can resolve permission names to the wrong tenant's IDs and return incorrect authorization results.

Fix:
initializeCache() now also clears the in-memory permissions collection (via clearPermissionsCollection()) and the transient $cachedRoles buffer, so the next permission check rebuilds from the newly-configured cache/tenant instead of reusing stale data.

Changes:

• src/PermissionRegistrar.php — initializeCache() clears in-memory permissions/roles state.
• tests/Integration/PermissionRegistrarTest.php — regression test asserting the loaded collection is null after initializeCache().
• docs/advanced-usage/cache.md — clarifies that initializeCache() now also discards the loaded collection.

Impact: No behavior change for typical single-tenant apps. initializeCache() is otherwise only called once at registrar construction, where $permissions is already null, so this adds no overhead there. It only changes behavior for the explicit-reinitialize-mid-request pattern our docs already describe, making that pattern actually work as documented.