D: stop renaming a parent of a nested gitlink during the run #99

Lane D follow-up to #81.

Why

#81 puts an empty read-only tmpfs at every gitlink path for execute and fix (--mount type=tmpfs,target=/work/<path>,readonly,tmpfs-mode=0555,tmpfs-size=4096). A top-level gitlink is fully protected: an agent cannot write into it, remove it or rename it (EROFS, EBUSY).

A gitlink below the top level (for example deps/inner) is not fully protected during the run. Tested in real Docker:

1. The agent renames a parent directory: mv deps deps2. This succeeds, and the mount moves to /work/deps2/inner.
2. The agent creates deps/inner again and writes anything there, including a full nested checkout with its own .git.

The inspection after the run reports this as nestedGitlinkContent, and the task goes to needs human. So nothing is committed. But docs/plan-format.md ("Submodules in version 1") asks for the protection during the invocation. #81 amended that section to record this gap.

Proposed

Find a mount layout or check that stops this during the run, then remove the exception from plan-format.md. Options to evaluate:

• Mount each parent directory of a nested gitlink so that it cannot be renamed, while its other children stay writable.
• Refuse execute and fix for heads with nested gitlinks, if no layout works.

Done when

• A real-Docker test renames a parent of a nested gitlink during an execute run, and the write at the old path fails (or the launch is refused).
• docs/plan-format.md and docs/implementation/agent-isolation.md no longer list the exception.

Refs: #81, docs/plan-format.md ("Submodules in version 1").