feat: add opt-in BoundaryAttest receipts for high-impact file operations

[cullenmeyers]

Summary

This is the narrow BoundaryAttest proof-of-concept discussed in #1.

It adds optional BoundaryAttest Interop Profile v0.1 receipts for three high-impact filesystem operations:

• write_file
• move_file
• delete_file

Receipt signing is disabled by default. Normal local usage requires no signing key or BoundaryAttest dependency and does not produce receipts.

Why this shape

The goal is not to replace the server's existing:

• allowed-path validation
• extension/file policy
• locking
• filesystem semantics
• MCP behavior
• authorization or logging

The receipt is only an optional evidence/export layer for cases where a selected filesystem operation may later need to be independently checked outside the original MCP/runtime.

Evidence captured

write_file

Binds:

• the materialized resolved target
• digest of the exact appended bytes
• previous file hash when applicable
• exact resulting file hash

The existing append semantics are preserved.

move_file

Binds:

• resolved source
• actual materialized final destination
• source/pre-move artifact hash
• post-move artifact hash

If the caller provides a destination directory, the receipt binds the actual destination/source.name path used by the operation.

delete_file

Binds:

• the exact pre-delete/pre-trash file hash
• materialized target/action
• successful send_to_trash result semantics

It does not pretend a post-delete artifact exists at the original path.

Receipt behavior

Receipts use the existing BoundaryAttest Interop Profile v0.1:

• Ed25519 signatures
• server_attested
• strict claim / signature / public_key_id envelope
• SPKI-derived public key ID
• exact artifact hashing
• independent verifier requiring a caller-supplied expected public key

Absolute local paths are not exposed directly in the portable target references; those use allowed-root-relative references.

Failure semantics

Filesystem operations are not transactional with receipt generation.

If the filesystem action succeeds but signing or receipt persistence fails, the action is not rolled back and is not reported as though it failed.

Instead, the normal success result is preserved with an explicit attestation-failure warning.