Add user-controlled filesystem access to Plan information requests

[taras]

Story

As someone using xmd plan or the shared <Plan> component, I want to control which project files an information request may inspect and approve a request for additional access, so planning can gather useful context without silently broadening filesystem access.

For example, an Agent asks XMD to read a related project's configuration. When that read lies outside the currently authorized scope, the user can see what access is requested and decide whether to grant it before the read occurs. Declining does not grant access.

Current gap

The Product Owner has chosen the same ordinary evaluation profile for xmd run and xmd plan in #762. Plan information requests select that profile's read class; file reading during planning is not deferred.

At the #762 architecture base, the ordinary profile admits self-closing <File /> reads through the existing host-filesystem provider. That provider resolves relative paths from the contextual working directory and enforces its documented stable-namespace containment checks. It does not offer an information-request approval flow. The profile does not currently expose globbing.

This issue owns the separate product decision about planning's authorized workspace scope and the user interaction for requesting additional access. It does not claim that #762 already delivers that policy or that existing containment is an operating-system sandbox.

Contract and design review

Settle these decisions with the Product Owner before implementation:

• How the initial authorized project scope is selected, whether it is confined to the caller's project workspace, and how that scope is shown to the user.
• How file reads and any admitted file discovery request additional access.
• What the approval grants: the exact operation or path scope, its lifetime, and its treatment on continuation.
• The exact approval and refusal wording, and behavior when interactive approval is unavailable.

The approved design provides the same product behavior for command and embedded Plan authorship. A request for additional access performs no out-of-scope read or discovery before explicit approval. Denial, cancellation, or an unanswered request never counts as approval. Approval does not authorize writes, processes, or unrelated capabilities.

Acceptance and discriminating evidence

• Demonstrate an in-scope read and an out-of-scope request through both Plan surfaces. Distinguish an implementation that simply reads everything using ambient host access.
• Show the requested scope before access, then exercise approval, denial, cancellation, and unavailable interaction. Instrument the filesystem boundary to prove no refused access occurs.
• A granted request cannot access a different path or perform a different operation outside its grant.
• Continuation follows the approved grant-lifetime policy without silently restoring broader authority or repeating a completed approval interaction.
• Apply the approved scope consistently to file discovery when discovery is admitted; discovery cannot reveal paths that reading policy protects.
• Document the exact host-filesystem enforcement guarantee and its limitations.

Dependencies and related work

• Add read-only XMD information requests to xmd plan #762 owns the shared-profile read-only information loop. This issue follows that work and is not a prerequisite for its delivery.
• Prevent xmd run filesystem operations from escaping the working directory #227 owns protection against concurrent host-path replacement. Reuse that enforcement work rather than duplicate it here.
• Quest: Enforce least authority across xmd workflows #536 owns general XMD least-authority architecture. This issue owns the Plan user journey and approval decisions, not that entire framework.

Out of scope

• Deferring the file reads admitted by Add read-only XMD information requests to xmd plan #762's shared profile.
• Executing the approved Plan during authorship.
• Choosing a new glob component or adding unrelated read capabilities.
• General Agent-native tool permissions or operating-system sandboxing.