feat(ffi): expose fs_mount_ro, and reject :ro/:rw in the Python profile parser

[dzerik]

Item (a) of #174, in the sequence you laid out: the fs_mount_ro ABI export plus a loud SDK rejection of :ro / :rw. Item (b) — sandlock_profile_parse and deleting the Python parser — is not here.

sandlock_sandbox_builder_fs_mount_ro

Mirrors sandlock_sandbox_builder_fs_mount: same arity, same move semantics, same null handling. fs_mount_ro was the only mount-related builder field without a C ABI setter, so no binding could express a read-only mount at all.

Tests drive the real contract rather than a non-null return: a read through the mount returns the host file's content, a write fails with EACCES and leaves the host bytes untouched, and a control fs_mount write in the same run succeeds and lands on the host. The read-only path is granted an explicit fs_write so that read-only winning over a broader writable rule is pinned rather than assumed.

Verified negatively: pointing the export at fs_mount turns three of the eight tests red, including the end-to-end one.

Python: :ro / :rw are refused

The core strips the suffix before splitting; the SDK's parser split on the first colon, so "/work:/host:ro" produced the host path /host:ro. Where no such directory exists the mount silently fails; where one does exist, the SDK mounts that directory read-write while the CLI mounts the intended one read-only. A profile asking to tighten access could quietly widen it.

Both forms are refused, with different messages, because the reasons differ. :ro cannot be honoured at all — Sandbox.fs_mount is a plain virtual-to-host mapping with no read-only channel. :rw is merely outside this parser's grammar and means what the mapping already does; a message claiming it would otherwise mount read-write would be false.

Recognising the suffix and dropping it would be worse than the status quo, as you noted; the code says so at the guard.

Two things worth your explicit attention

1. I tightened fs_mount as well, which is shipped behaviour.

Review caught that the empty / non-UTF-8 guard on the new setter left its twin open: sandlock_sandbox_builder_fs_mount still degraded both arguments with to_str().unwrap_or(""). An empty virtual path is a prefix of every guest path, so ChrootCtx::is_mounted matches the whole tree and short-circuits can_read and can_write to true — one bad argument voids the allowlists. Python and Go both reach the sandbox through that symbol, so leaving it open would have left the hole reachable from every binding.

The predicate now lives in one private mount_pair() used by both setters. This does change behaviour for a caller passing an empty path: previously a tree-wide mount, now none. Say the word and I will split it out or drop it.

2. The doc comment no longer promises immutability, because of #179.

While reviewing this I found that a guest holding any writable mount on the same host filesystem can hard-link a file out of a read-only mount and write through the alias — the linkat handler gates only the new path. The same trick defeats fs_deny. Filed as #179 with a reproduction; it is pre-existing core behaviour that predates this export, and picking the right predicate looked like your call rather than a mechanical mirror of renameat2, so there is no core change here.

What this PR does carry is honest wording: the doc describes a mount-shaped access rule, not an immutability guarantee for the host files behind it.

Not included, deliberately

No sandlock_profile_parse, no Python parser removal, no Python or Go wiring of the new symbol, no version bump. Declaring the symbol in the SDK's eager _builder_fn table would break SDK import against an older libsandlock_ffi.so, so that belongs with (b), where the profile path changes anyway.

The header is regenerated with the pinned cbindgen from cbindgen.toml and is byte-identical to a fresh run.