v0.1.1

Three changes to the filesystem capability surface, all additive. Existing callers build without changes.

CANONICAL ORDER FROM fs-read-dir

directory-list yields the filesystem's order, which is arbitrary, so every client had to pick its own or show an arbitrary one. fs-read-dir now sorts at the source: each consumer (Slate browsing the local machine via Lantern, a remote node via Familiar) gets the same order without duplicating the rule, and no client pays to re-sort per render.

Four tiers: all directories before all files, hidden before visible within each, so a repo reads .git/ then src/ then .gitignore then README.md. Alphabetical within a tier, case-insensitively (a listing is read by a human, and ASCII order files Zebra before apple), with the case-sensitive name as a final tie-break so names differing only in case get a total, deterministic order.

This is presentation policy in a capability library, which is worth stating rather than leaving to be discovered: it is a deliberate DEFAULT, not a mandate. A client wanting date or size order re-sorts on top; it just no longer pays for an order it did not ask for.

fs-home: THE BROWSED MACHINE'S HOME

A client that wants to expand "~" must not hardcode a host convention. The home that matters belongs to the machine being browsed, which for a remote node is not the machine doing the typing, so it has to come from the capability surface like every other fact about that filesystem.

Grant-checked as a read OF the home directory, deliberately: a principal scoped to /srv has no business learning where the owner's home is, and anything it would do with the answer is denied anyway. Under the in-process desktop posture (grant-allow-all) it is simply always allowed. Raises when HOME is unset (a bare service environment); callers should read that as "no home to expand", not as fatal.

THE SORT ITSELF

The first cut hand-rolled a merge sort on the belief that the runtime exposes no sort. It does: (sigil list) has list-sort, predicate first per SRFI-132. sort is unbound, which is what sends people looking, and two modules independently wrote their own as a result.

The hand-rolled one was also worse, and worse exactly here: its merge built results with (cons x (merge ...)), not in tail position, so it cost O(n) stack and overflowed at 10,000 elements (measured). A directory listing is precisely the unbounded input, and /gnu/store is about 190k entries. list-sort accumulates and append-reverses, so it is tail-recursive and stable.

VERSIONING

Patch, not minor. The pre-1.0 convention reserves minor for breaking API changes, and this changes output ORDER, not any signature. Practically, lantern-system pins ^0.1, and a 0.2.0 would not resolve under that caret range, which is exactly the breakage signal minor is reserved for.