AssetManager and Screen lifecycle: where should reference counting and unloading live?

I'm designing a libGDX game (assume 1.12.x, desktop and Android targets) that uses a single shared AssetManager across multiple Screen implementations: a loading screen, a menu screen, and several level screens. The loading screen polls update() and reads getProgress() to drive a progress bar, which works fine.

The unresolved part is the boundary between the manager's reference counting and screen disposal. If a level screen calls unload() for its textures in hide() or dispose(), but another screen (or a cached sprite pool) still holds retrieved Texture references, I risk disposing GPU resources that are still in use. Conversely, if screens never unload, the manager keeps everything resident and memory grows across levels.

I also want some assets (UI skin, fonts) to stay permanently loaded while level assets rotate, and it's unclear whether that split should be one manager with disciplined unload calls or two separate manager instances.

Which component should own the decision to unload: the screen that loaded the asset, or a central coordinator tracking which screens are active?

Is mixing manually disposed assets with AssetManager.unload() on the same resources supported, or does it corrupt the manager's internal reference counts?