Astra: security review of stage B's tenant-directory reads and writes

Review cfb4314d..3194d674 on region-ha-1b-next-build. The two commits are dca370c2 (reads) and 3194d674 (writes).

Context. Relocation installs and flushes nested instance rows. The instance directory is writable by the tenant. Before these commits, stage B read and wrote it with plain path calls. That meant a planted symlink, FIFO or oversized file could redirect the agent's reads or writes, block it, or exhaust its memory.

The fix. Every read and write now goes through main's instancefs, the same code main's instance-key path uses:

• readInstanceFile, EnsureDirBeneath, WriteAtomic and RemoveBeneath;
• a new OpenDirBeneath and OpenRootBeneath (which builds an os.Root from the open directory via /proc/self/fd/N);
• a new hostfiles.RestoreRoot/SyncDirAt, with Restore/SyncDir delegating to them.

Judge:

1. Can a tenant still redirect, block or exhaust any agent read or write in stage B's relocation flush or install? Consider symlinks, FIFOs, hard links, oversized files, and races between check and use.
2. Is OpenRootBeneath via /proc/self/fd sound? Can the link resolve to anything other than the opened directory?
3. Does RestoreRoot stay inside the root? Restore still checks then opens within it. Is that only a denial-of-service risk, or worse?
4. Do Restore/SyncDir behave exactly as before for main's callers (moves)?
5. Is there any second implementation of a safe read or write?

Give findings P1/P2/P3 with file:line, then a verdict.