Harden trusted workspace authority against external target and transport drift

[LZH-YS1998]

Context

Issue #38 is fixed for its primary boundary: untrusted project configuration is rejected before parsing, and PR #48 invalidates trust when the project configuration source or normalized effective authority changes. The regression harness in PR #47 covers the local-MCP and credential-bearing LLM sinks.

This follow-up tracks defense in depth after a user has explicitly trusted a workspace and the YAML authority itself remains unchanged. Configuration fingerprints must not be represented as pinning mutable external objects.

Remaining hardening

• Resolve and bind local MCP executable, script, arguments, and working-directory identities immediately before spawn; define how content or symlink-target changes invalidate approval.
• Minimize or explicitly bind inherited child-process environment instead of treating implicit ambient variables as approved authority.
• Reject or re-authorize credential-bearing HTTP redirects whose origin differs from the evaluated remote MCP or LLM endpoint.
• Bind selected provider, model, default route, endpoint, and credential selector to the declaration evaluated at the real request sink.
• Close remaining time-of-check/time-of-use windows with sink-adjacent validation.
• Define whether repository revision changes require renewal when security-relevant declarations and referenced targets are unchanged.

Acceptance criteria

• Mutation tests cover executable or script content, symlink targets, relative resolution and working directory, child environment, redirect-origin drift, and provider/model default-route changes.
• Tests use temporary directories, synthetic values, marker-only child processes, and loopback servers only.
• Each blocked-path test includes a trusted positive control.
• Documentation distinguishes workspace/config trust from external object integrity and remote-origin guarantees.

Related: #38, #47, #48.