feat(#208): link MCP views to Artifacts hub for YAML editing (release 5)

[gozen59]

Summary

• Expose artifact IDs in MCP resolvers (mcpPrompts.ts, mcpCustomTools.ts) so resolved views know which source artifact to edit.
• Add Edit in Artifacts links on service MCP tabs (/services/{id}/mcp-prompts, /services/{id}/mcp-custom-tools) pointing to /services/{id}/artifacts/{artifactId}.
• Fix service-context help links: replace experimental /artifacts with the service Artifacts hub.
• Extend the same navigation on global MCP pages (/mcp-prompts, /mcp-custom-tools) when serviceId / artifactId are resolved.
• Add empty-state Create Prompts artifact / Create CustomTools artifact links where relevant.

No Monaco, schema, worker, or backend changes — MCP routes stay read-only; editing remains in the Artifacts hub (lots 1–4).

Test plan

• Open a service with a RESHAPR_PROMPTS artifact → MCP prompts tab shows YAML in ScrollableCode (read-only) and Edit in Artifacts opens the correct artifact in Monaco.
• Open a service with a RESHAPR_CUSTOM_TOOLS artifact → MCP custom tools tab shows Edit in Artifacts on the YAML collapsible.
• Service without Prompts artifact → empty state shows Create Prompts artifact → /services/{id}/artifacts/new?kind=Prompts.
• Service with tools from operations only (no CustomTools artifact) → empty state shows Create CustomTools artifact.
• Help text Artifacts link on service MCP tabs points to /services/{id}/artifacts (not /artifacts).
• Global /mcp-prompts and /mcp-custom-tools: resolve an MCP URL → Edit in Artifacts appears when artifact source exists.
• Confirm no Monaco bundle loaded on MCP routes (Network tab: no monaco/worker requests on MCP pages).
• npm run check passes (already verified locally).

[lbroudoux]

I think we need to further discuss this as I'm not sure what we'd like to keep in the future...

I tend to think that we don't need "MCP Custom Tools" or "MCP Prompts" thumbnails as is ... as everything now should be managed via the "Artifacts" tab. However, I think there are useful features here like the one that extracts "tools" or "prompts" from the YAML artifacts.

I like the idea of thinking of "prompts", "resources", "custom tools", and the things we attach via artifacts as additional capabilities that come to enrich the default service definition. Maybe we should add a Capabilities section in the "Overview" tab of a Service...

I would say then that 4 tabs are enough => Overview (with capabilities), Artiacts, Configuration Plan, and Exposition.

What do you think?

[gozen59]

Agree — separate MCP tabs are redundant now that Artifacts is the edit surface. The resolution views (effective prompts/tools) are still useful and fit better under Capabilities on Overview.

This PR only wires navigation + artifactId in resolvers; that stays relevant wherever we show the resolved view. I’d merge incrementally and do tab consolidation in a follow-up — unless you’d rather hold this until Overview/Capabilities is designed.