Expose MCP feature through Slint platform setup

[tilladam]

Summary

• add a public slint/mcp feature that wires through the selector and testing backend MCP support
• initialize the embedded MCP server from slint::platform::set_platform(), matching the existing backend-selector initialization path
• make MCP initialization idempotent while allowing retries if hook registration fails
• keep slint/mcp from compiling the public testing-backend helper APIs and suppress generated protobuf dead-code warnings in the generated proto module

Notes

This keeps the current MCP implementation in i-slint-backend-testing because it reuses the existing introspection/search infrastructure. A possible future cleanup is to split that shared introspection layer into its own internal crate/module, with clearer boundaries:

• accessibility: semantic runtime contract for assistive technologies
• introspection/devtools: debug/test element tree, handles, geometry, metadata, and search
• MCP: transport/server layer built on introspection
• testing backend: fake backend, mock time, deterministic fonts, and test utilities built on introspection where needed

That split is orthogonal to this PR, but would avoid making MCP look conceptually tied to the testing backend long term.

Verification

• cargo build -p slint --release --no-default-features --features std,compat-1-2,mcp
• cargo check -p i-slint-backend-testing --features internal

[tronical]

cc @ogoffart

I've been thinking along the same lines of having just a public MCP feature and otherwise no changes needed. It won't expose additional api.

Implementation wise I think it would be better not to do the shadowing and instead use the same approach as the system testing hook.

[tronical]

I’m very confused. Why is all the extra code necessary when we have

slint/internal/backends/selector/lib.rs

Line 175 in d536497

#[cfg(feature = "mcp")]

?

Right now, once has to merely enable the MCP feature in the selector and instead we could say that one need to enable it on the slint crate instead and that forwards.

But clearly I’m missing something as this diff does so much more. What am I missing?

[tilladam]

The key scenario the selector's with_global_context at line 175 doesn't cover is custom platform users — applications that drive their own event loop and call slint::platform::set_platform() directly, bypassing the selector entirely. For those apps, with_global_context is never called, so MCP would never initialize.

With add_platform_init_hook and slint::mcp::register(), custom platform authors can opt into MCP without coupling back into the selector. This is the same pattern set_window_shown_hook already established in i_slint_core::context.

So in summary: if the goal is only "make mcp work for selector-based apps," then yes, just forwarding the feature is sufficient and simpler. But if we want custom platform authors to be able to opt into MCP (which is the stated motivation for this PR), the hook mechanism is needed and slint::mcp::register() is the right surface for that.