[Improvement] Add trust-boundary restrictions for API-to-MCP imported services

Improvement Description

The current API-to-MCP flow lets an authenticated tenant user import an OpenAPI definition / service target and then have the backend perform outbound requests to that imported target.

In local validation, registering a service/tool that pointed to a local HTTP listener caused the backend to send a real request to that listener. That means the current design already supports arbitrary backend egress to caller-controlled targets.

Feature-wise this is useful, but from a trust-boundary perspective it would help to define what targets are intentionally allowed.

Proposed Solution

Before adding more API-to-MCP functionality, it would be helpful to align on a policy for imported service targets, for example:

1. whether API import should be limited to admin-level users;
2. whether loopback, private-network, link-local, metadata, or cluster-internal targets should be denied by default;
3. whether an allowlist / explicit opt-in configuration should be added for trusted internal APIs.

Additional Information

This is related to the feature track in #2187 / #2765, but it is narrower: it is specifically about the trust boundary for imported service targets, not about the API-to-MCP feature itself.

Start with the API-to-MCP import and service/tool registration flow that performs outbound requests. Review related feature issues #2187 and #2765, then identify where imported targets are accepted and requests are dispatched. Done requires a decided trust-boundary policy and corresponding implementation, but this issue names no files, tests, or acceptance criteria.