fix(runtime): propagate unexpected errno from realpathSync

[wasaybuilds]

Closes #1838.

• The bridge's realpathSync segment loop special-cased ELOOP/ENOENT/ENOTDIR and break-ed on every other errno, then returned the partially resolved prefix as if it were the resolved path. Callers got a valid-looking wrong path — typically the parent directory — instead of the failure.
• Unexpected errnos now go through the existing throwNormalizedFsBridgeError, so EACCES and friends reach the guest with the right code, errno, syscall and path.
• The ENOENT branch now uses createFsError instead of hand-rolling the error, which also gives it the errno field it was missing.

Verified against the real resolution loop with the host lstat stubbed, before and after:

=== BEFORE ===
  realpathSync("/ok/file.txt")                 -> "/ok/file.txt"
  realpathSync("/blocked/secret.txt")          -> "/blocked/secret.txt"
  realpathSync("/blocked/sub/deep/secret.txt") -> "/blocked/sub"
  realpathSync("/missing/x")                   threw ENOENT errno=undefined

=== AFTER ===
  realpathSync("/ok/file.txt")                 -> "/ok/file.txt"
  realpathSync("/blocked/secret.txt")          threw EACCES errno=-13 syscall=realpath
  realpathSync("/blocked/sub/deep/secret.txt") threw EACCES errno=-13 syscall=realpath
  realpathSync("/missing/x")                   threw ENOENT errno=-2

The third line is the reported symptom: a directory path returned where a file was requested, which is what surfaced as EISDIR in the Claude CLI.

I did not add a committed regression test — the only home I found for guest fs semantics is a VM-level suite I can't run locally (no Rust toolchain on this machine). Happy to add one if you point me at the harness you'd want it in.