Expand Assets Manager rule scopes for reusable page patterns

Summary

Expand Assets Manager rule scopes so users can apply and maintain asset decisions across repeated templates and archive contexts without managing every page one by one.

Why this matters

Perform already lets users disable assets globally and re-enable them for the current URL or selected post types. That works for small sites, but it becomes operationally expensive on larger sites with many posts, taxonomy archives, builder templates, or repeated landing-page patterns.

If Perform is going to scale with agencies and content-heavy sites, asset rules need to be reusable and easier to reason about.

Proposed scope

• Add broader rule scopes for Assets Manager decisions, such as:
  • post type archives
  • taxonomy archives
  • common template contexts (home, blog index, search, 404, singular)
  • optional URL-prefix rules if they can be validated safely
• Show an at-a-glance rule summary so users can understand why an asset is enabled or disabled on the current page.
• Preserve the current per-object exception flow for backwards compatibility.
• Reuse existing storage concepts where possible instead of introducing a second rules engine.

Acceptance criteria

• Existing perform_assets_manager_options rules continue to work unchanged after the update.
• Users can apply an asset rule to at least one archive or reusable template scope from the Assets Manager UI.
• The current page clearly indicates which scope caused a rule match.
• Conflicting rules resolve predictably and are documented in the UI.
• New rule scopes are covered by tests for save/load behavior and runtime evaluation.

Implementation notes

• src/Modules/Assets/AssetsManager.php already stores current and post_types exceptions and contains archive-related handling behind perform_assets_manager_settings['separate_archives']. That existing shape is a good starting point for a more complete rule model.
• Keep runtime checks cheap; rule evaluation runs on frontend asset loading hooks.
• Any new UI should stay aligned with WordPress component patterns already used in the settings experience.

Compatibility and security considerations

• Preserve all existing option keys and storage contracts.
• Do not make rule matching depend on unsanitized request data.
• Prefer additive scopes over changing the meaning of current "everywhere" and "current URL" behaviors.

Suggested labels / milestone

• enhancement
• area: assets-manager
• area: admin-ui
• area: performance
• priority: medium
• status: needs-spec
• Milestone: 1.7.0

Start with src/Modules/Assets/AssetsManager.php, especially the current and post_types exceptions and separate_archives handling. Trace how rules are saved, loaded, and evaluated on frontend asset hooks before defining the added archive and template scopes. Done means the UI supports at least one reusable scope, explains matches and conflicts, preserves existing options, and includes save/load and runtime tests.