Distinguish tool discovery from tool invocation in authorization and audit

Summary

The current authorization model uses the tool:call verb for both the ingress check
on tool listing requests (tools/list) and for egress response filtering of the tool
list. This conflates two semantically distinct operations and creates two practical
problems:

1. Policy granularity: There is no way to write a Cedar policy that allows a
   client to discover which tools are available without also granting permission to
   invoke them. This prevents least-privilege policy designs.

2. Audit ambiguity: An audit trail showing tool:call events cannot distinguish
   between a user who listed tools (a read-only, side-effect-free operation) and one who
   actually invoked a tool (a potentially mutable action). This reduces the forensic
   value of logs.

Proposed Change

Introduce a clear semantic split:

• Ingress: Add a new tool:list verb (mapped to MCPOperationList on
  MCPFeatureTool) so that incoming tools/list requests are authorized independently
  of tool:call.
• Egress: Change the per-tool filtering of tools/list responses from tool:call
  to tool:read (mapped to MCPOperationRead on MCPFeatureTool), reflecting that
  determining visibility of a tool is a read-only discovery check, not an invocation.

The resulting verb taxonomy becomes:

Impact

Breaking change for users with existing Cedar policies. Any policy that previously
used tool:call to control access to tools/list will need to be updated to use
tool:list (for the list request itself) and/or tool:read (for per-tool visibility
in the response).

Start by tracing authorization for incoming tools/list requests and the per-tool filtering of tools/list responses, focusing on MCPFeatureTool and the MCPOperationList and MCPOperationRead mappings. Update the verb handling so tool:list governs ingress, tool:read governs visibility, and tool:call remains invocation, with corresponding Cedar policy and audit behavior covered by the repository's relevant tests.