Copilot for different project types

[nighca]

Background

As part of #2800, Copilot should work correctly when the user is viewing or editing projects of different project types.

At the product level, Project Type is a first-class concept. Copilot should follow the currently active project type instead of staying implicitly coupled to the existing SPX / game implementation.

Current status:

• The frontend UI radar mechanism already exists.
• The frontend Copilot module already supports dynamic context provider and tool registration.
• The current implementation still keeps many SPX-specific context providers, tools, and prompt assumptions in the default Copilot path.

Scope

This issue covers the project-type-agnostic Copilot mechanism, plus the integration needed so Copilot switches correctly with the currently active detail page / editor page for already supported project-type implementations.

This issue does not include integration work for future project types that are not yet otherwise supported by Builder.

Specifically:

• Keep CopilotRoot responsible only for project-type-agnostic registrations.
• Move project-type-specific context providers, tools, and related Copilot registrations to the corresponding project page / project editor logic, so they are added and removed dynamically with page navigation.
• Move runtime-related context and events such as runtime output and normal runtime exit notifications to the corresponding project editor logic instead of keeping them in the default root registration.
• Ensure switching between supported project pages / editors does not leave stale context, tools, or page-specific assumptions in the current Copilot session.
• Introduce a frontend-provided mechanism for Copilot to dynamically load class-framework-specific knowledge / skills instead of baking SPX-specific knowledge into the default path.
• Load such skills as user messages rather than system messages.
• Keep the default system prompt focused on Copilot's role and responsibilities inside XBuilder at the platform level rather than on any specific project type.
• Apply the new skill-loading mechanism to the in-product Copilot prompt path(s) that currently depend on SPX-specific knowledge.

Boundaries

• This issue is about the Copilot capability layer, not the routing / page-structure work itself. Type-specific page routing remains in #2804 and #2805.
• The goal here is to make the mechanism generic and to wire it into the detail/editor pages that already exist for supported project types.
• Adding Copilot support for any future new project type should be tracked separately once that project type itself is introduced.
• The existing UI radar mechanism is background / prerequisite context for this issue, not a work item inside this issue.
• cmd/claudegen is out of scope for this issue.
• internal/aidescription/ is out of scope for this issue.

Notes

• This issue does not require a dedicated API parameter for project type. The dynamic loading mechanism may rely on model-visible context, class framework identifiers, and skill-loading behavior instead.
• Each project type may map to a class framework ID, and class-framework-specific skills should make their target class framework ID explicit.
• The frontend-provided skills should remain constrained by the platform-level system prompt so Copilot keeps its XBuilder-specific role and is not repurposed into a general assistant.

Done When

• CopilotRoot only keeps project-type-agnostic registrations.
• Project-page / project-editor logic dynamically registers and unregisters the context providers, tools, runtime-related events, and class-framework-specific skills relevant to the active page / project type.
• Copilot can dynamically load the relevant class-framework-specific skills for the current situation instead of depending on SPX-specific defaults in the root path.
• Such dynamically loaded skills are sent through user messages rather than system messages.
• The default system prompt remains XBuilder-scoped and does not depend on any specific project type.
• Switching between supported project pages / editors does not leave stale Copilot context, tools, or knowledge behind.