feat: add support for 'tools' permission

[beaufortfrancois]

Motivation and Context

This change adds support for the 'tools' permission from the WebMCP specification, mapping it to the Permission Policy 'tools' feature.

How Has This Been Tested?

I've tried it locally by adding this code in my files:

// mcp-app.ts

(document as any).modelContext.registerTool(
  {
    name: 'webmcp-get-time',
    description: 'Returns the current application time.',
    execute: () => {
      const time = new Date().toISOString();
      return { content: [{ type: 'text', text: time }] };
    },
  },
  { exposedTo: ['http://localhost:8080'] },
);

// server.ts

  const permissions = { tools: {} };
  
  registerAppResource(
    server,
    resourceUri,
    resourceUri,
    {
      _meta: { ui: { permissions } },
      mimeType: RESOURCE_MIME_TYPE,
    },
    async () => {
      const html = await fs.readFile(path.join(DIST_DIR, 'mcp-app.html'), 'utf-8');

      return {
        contents: [{ uri: resourceUri, mimeType: RESOURCE_MIME_TYPE, text: html }],
      };
    },
  );

Then, I used WebMCP - Model Context Tool Inspector extension to verify it was properly registered. Without this PR, registration fails because of the missing allow=tools on both iframes.

Breaking Changes

Nope.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed (I've assumed schema.json will be part of the documentation)

Additional context

[beaufortfrancois]

@ochafik Please review this PR

[domfarolino]

I think this PR is reasonable and looks good. However, we should talk about use cases more, since it's not totally clear how WebMCP tools inside of an MCP App should interact with so-far "official" MCP App tool calling that landed in #72.

With this PR, an MCP App author has to think about two different types of tools:

1. Tools that integrate directly with the MCP App protocol, and are exposed to the host through mechanisms defined in the spec
2. WebMCP tools that can be exposed to the host explicitly via exposedTo, and also exposed to built-in agents in the browser.

The latter part of (2) is the new capability this PR brings MCP Apps. While I'm supportive, I will note that it might be confusing if we don't integrate more directly with MCP Apps tool calling. For example, is the user really expected to use a built-in browser agent (to run WebMCP tools) while also viewing a chat host that's serving MCP App? Which agent should the user talk to? If they talk to the web-based chat agent, then WebMCP tools are only useful if the agent host knows to read WebMCP tools and MCP App tools. If they talk to the built-in agent, then only WebMCP tools are useful, since the built-in agent doesn't know anything about "MCP App tools", or other interactions between View <-> Agent brokered by the MCP Apps spec.

(Personally, I'd like to see MCP App tool calling be based off of WebMCP, as discussed in #35 (comment). But we should discuss it more!)