Open custom tools in Content Drive with their content types locked #37931

Description

Custom tools are menu items admins create for a set of content types or base types, such as "Blogs". Today they open the legacy Content Search, filtered to those types. When the feature flag from #37929 is on, a custom tool should open in Content Drive instead, showing only the tool's types, and users shouldn't be able to widen it to other types.

It's opt-in: with the flag off, tools work exactly as they do today. Content Search, Site Browser and their own redirects (#37832) aren't affected by this flag.

Proposed approach (frontend only):

• MenuGuardService already loads the menu, and every menu item carries the tool's baseTypes and contentTypes in initParams. When the flag is on and the requested /c/:id is a custom tool (c_ prefix and portletSource: db), the guard redirects to Content Drive with the tool's types in the URL. Content Drive makes no extra request.
• The tool's types are the only types users can filter on. Whatever the admin selected for the tool, as base types or content types, is exactly what the type filter offers in Content Drive. Users can filter by any of them, and by nothing outside them.
• The types travel in their own params, separate from filters. Proposed names: lockedContentTypes and lockedBaseTypes.
• Base types win. When a tool has base types, Content Search ignores its content types (ViewContentletAction.resolveContentTypes). Content Drive's search does the opposite when it gets both (content types win). So the guard sends only lockedBaseTypes when the tool has base types, and lockedContentTypes only when it has none.
• Content Drive keeps the locked types in its store and merges them back the same way it restores the default language (withFilterDefaults). That way Clear all and removing a chip can't drop them.
• The tool's view mode travels too. Every tool stores a dataViewMode (list or card, set in the tool's form and returned in initParams). The guard sends it as its own param (proposed name: viewMode), and Content Drive opens in the matching view: list opens the table, card opens the grid view from Add a grid view to Content Drive #37930. Until the grid view exists, card falls back to the table.
• Reuse feat(content-drive): replace Content Search and Site Browser for Content Drive users (#37759) #37832's Content Drive redirect helpers in MenuGuardService rather than duplicating them. Build this after feat(content-drive): replace Content Search and Site Browser for Content Drive users (#37759) #37832 merges.

Acceptance Criteria

Flag off

• Clicking a custom tool opens Content Search exactly as it does today.

Flag on: opening a tool

• A tool with only content types (for example Blog and Activity) opens Content Drive listing only Blog and Activity content, across the whole site.
• A tool with base types (for example File Asset) opens Content Drive listing only content of those base types.
• A tool with both base types and content types behaves like Content Search: only its base types apply, and its content types are ignored.
• The sidebar highlights the tool the user clicked, not Content Drive.
• Reloading the page keeps the same locked view.
• A tool saved with the list view opens Content Drive in the table view.
• A tool saved with the card view opens Content Drive in the grid view (Add a grid view to Content Drive #37930). If the grid view hasn't shipped yet, it opens in the table view with no error.

Flag on: the lock

• The type filter offers only the tool's own types: its content types, or its base types when it has base types. Users can filter by any of them (for example only Blog, in a Blog and Activity tool), and can't pick a type outside the tool.
• Clear all and removing filter chips never remove the tool's types.
• Adding another type to the filters param in the URL doesn't add it to the results.
• Every other filter (search, language, status, workflow, field filters) works normally and can be changed or cleared.
• The "Add new" menu filters its content types the same way the type filter does: only the tool's content types, or, when the tool has base types, only the content types under those base types. For example, a File Asset tool offers no Blog, and a Blog tool offers only Blog.
• Upload is hidden.

Flag on: access

• A user who has the tool in their menu but not Content Drive can open the tool in Content Drive.
• If that user removes the locked params from the URL, they're sent to their first portlet, the same as opening any portlet they don't have.
• Locked params that don't match a custom tool in the user's menu send the user to their first portlet.

Open question (confirm with the developer in the spec)

• Should a tool show folders at all? The current leaning is no. Content Drive already hides folders in the list whenever a type filter is set, so the open part is the folder tree in the sidebar and New Folder in the "Add new" menu. Decide this during the spec before writing the acceptance criteria for it.

Priority

Medium

Additional Context

• Blocked by Add a feature flag for opening custom tools in Content Drive #37929 (the feature flag). Build after feat(content-drive): replace Content Search and Site Browser for Content Drive users (#37759) #37832 merges.
• Legacy reference: Content Search reads dataViewMode from the tool's init params in view_contentlets.jsp to pick list or card.
• Checked against a local instance with the REST API: tools store comma-separated lists of both types, /api/v1/menu returns them in initParams, the legacy screen applies base types over content types, and Content Drive's search applies content types over base types.
• The card view depends on the grid view in Add a grid view to Content Drive #37930. This ticket can ship before it, with card falling back to the table.
• Out of scope: saving the rest of a Content Drive view (status, language and so on) into a tool, and creating tools from Content Drive. Both are a later phase.