Draft: Spike: Fetch foundational agents from the FixedItemsModel

What does this MR do and why?

This is a basic spike to explore the idea of having AI Catalog foundational items (for now just agents) get loaded from the Ai::FoundationalChatAgent fixed item model, so that we don't need to store any foundational items in the database.

The items get converted to SQL VALUES and merged with the regular catalog items. This way, any filtering and pagination can work natively. They are then returned to the front end and given a unique url such as explore/ai-catalog/foundational_agents/security_analyst_agent-v1 which users can visit to see more info.

The benefits for this approach are:

• It works on more platforms
  • It works automatically on Self-Managed and dedicated without any seeding
  • Same for Cells. The current approach will cause issues with Cells on .com since the foundational agents will need to be created in each Cell
  • Works out of the box in GDK as well
• We can show the items in the explore page, and all the filtering and pagination we have now or add in the future should work, without needing duplicate logic

Steps remaining

• Do not show the database foundational agents when showing synthetic items (on SAAS)
• Extend to also work with foundational flows
  • Find a way to add foundational flows to projects without item_consumers referencing items in the database
• Specs (only backend have been done)
• Clean up code
• Show more information in the show page
• Handle different organizations
• Do not require created_at and updated_at in the ::Types::Ai::Catalog::ItemInterface so that we can remove them from the foundational agents.
• Put it behind a feature flag, so it can be easily disabled if it causes issues
• Break this up into smaller more reviewable MRs

Alternative approaches

• I tried the same approach, but using single table inheritance, so that Ai::FoundationalChatAgent inherits from Ai::Catalog::Item and we delegate to that type for foundational agents. This ended up causing a lot of issues and it felt like I was fighting against Rails. (E.g. the fixed items model was complaining about many attributes which need to exist on the regular records, but don't exist for foundational agents)
• Use a separate finder to query for the foundational items in Ruby, and mix them in to the result set, handling pagination and everything. This seems like more work and we'll need to support 2 different finders and update any filtering and pagination in 2 places whenever our rules change.

References

Screenshots or screen recordings

How to set up and validate locally

• Enable the ai_catalog_synthetic_foundational_items feature flag: Feature.enable(:ai_catalog_synthetic_foundational_items)
• Go to http://gdk.test:8080/explore/ai-catalog/agents/ and see the foundational agents.
• Click on them to see the show page

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #592038 (closed)