Add a contextual File.Delete component for contained file removal

[taras]

Story

As a workflow author, I want to remove one file through ordinary Executable Markdown, so a retained Workspace proposal can delete obsolete content without receiving a filesystem handle or command-execution authority.

Authoring contract

<File.Delete path="obsolete.md" />

File.Delete is an ordinary contextual component with one required non-empty string prop, path. It is self-closing, accepts no content, renders nothing, and returns no caller-visible value. as therefore has nothing useful to bind.

The path resolves relative to contextual Env.cwd, exactly where the element is written. The operation removes one non-directory entry:

• a regular file is removed;
• a final symlink is removed as a link without following or changing its target;
• a missing entry succeeds as an idempotent no-op; and
• a directory is refused, even when empty.

There is no recursive form, force prop, glob, multiple-path prop, trash, restore handle, or implicit directory cleanup.

Containment and authority

Reject an empty path, an absolute path, and a lexical .. escape before mutation. Resolve existing parent ancestors and refuse a parent symlink that would place the named entry outside Env.cwd. Removing a final symlink changes only the contained directory entry and therefore does not grant access to its target.

The component makes no host filesystem call directly. It extends the contextual Files API with the semantic operation required to remove one file entry. The ordinary host Files provider implements the same contract for xmd run; the workflow Files provider performs it against the selected run-owned Workspace through the existing transaction boundary.

Generated source receives no deletion authority merely because the component exists or is registered. #369 owns generated-XMD admission. After its initial Dir plus paired File:write slice is delivered, this issue also owns adding the exact pinned File.Delete identity to the standard Deno workflow host's write table and the focused admission evidence. A host without that pinned identity continues to refuse generated deletion.

Durability and failure

Under xmd workflow, one successful invocation is one ordinary Workspace-local durable effect and one Workspace transaction. Its Workspace mutation and journal completion commit atomically under #365. Completed replay restores completion without deleting again; partial replay reaches the operation against the retained Workspace frontier.

An ordinary missing entry is successful, not a failure. An invalid path, directory target, containment refusal, provider refusal, or filesystem failure changes nothing and follows the ordinary component failure contract. The operation publishes no synthetic mutation receipt; its durable effect record is the authoritative account.

Acceptance

• <File.Delete path="file.txt" /> removes one contained regular file and renders nothing.
• Removing an already-missing file succeeds, changes nothing, and renders nothing.
• Removing a final symlink removes the link and leaves its target unchanged, including when the target is outside Env.cwd.
• An empty path, absolute path, lexical escape, escaping parent symlink, or directory target is refused without changing the Workspace.
• Paired content is refused before any mutation.
• The ordinary host and workflow Files providers implement the same semantic operation without the component selecting a runtime.
• A workflow mutation and its durable completion commit atomically; completed replay performs no second removal.
• The standard generated-XMD write policy admits deletion only by this component's exact pinned identity and only when the host supplied it. Same-name repository components, registrations, middleware replacement, and another loaded package copy do not satisfy that identity.
• A generated fragment mixing admitted deletion with any unadmitted syntax performs no generated effect because Evaluate Agent-generated XMD through a constrained allowlist #369 preflights the whole fragment.
• Core, runtime-provider, workflow transaction/replay, and generated-admission regressions cover the observable contract.
• The executable-MDX and workflow-Workspace specifications describe the component, containment, durability, and generated-admission boundary.

Dependencies and delivery order

• Commit Workspace mutations and journal results atomically #365 supplies the atomic Workspace mutation and journal boundary.
• Add the xmd workflow start/resume filesystem vertical slice #366 supplies retained workflow execution and its selected Workspace.
• Evaluate Agent-generated XMD through a constrained allowlist #369 supplies generated-XMD write admission. Its initial mutation slice does not wait for this issue; the pinned deletion identity is integrated after both ordinary deletion and write admission exist.
• End goal: PR ✨ Compose and certify the supervised adversarial implementation workflow #181. That workflow cannot consume generated deletion until this issue is delivered.

Out of scope

• Directory removal, recursive removal, globs, or several paths in one invocation.
• Returning a path, boolean, receipt, removed contents, or restoration handle.
• Host paths outside contextual Env.cwd.
• Direct Agent filesystem or command access.
• Granting generated source admission; only Evaluate Agent-generated XMD through a constrained allowlist #369's host-owned policy can admit the pinned identity.

[taras]

Delivered in full. PR #570 shipped the ordinary contextual <File.Delete> component, host and workflow Files providers, containment, transaction, replay, and cross-runtime evidence. PR #574 added its exact pinned identity to the standard generated-XMD write policy and proved preflight, substitution resistance, and replay. No #181 delivery work remains here.