Simple/JSON.purs imports Pathy for the four ReadForeign path instances and
the four WriteForeign SandboxedPath ones, but the package declared only
erl-kernel and was relying on erl-kernel's own extra_packages entry to
supply pathy transitively.

erl-kernel v1.0.0 drops pathy, so the undeclared dependency stops being
satisfied by accident. No code changes: verified by building against
erl-kernel v1.0.0 with only this declaration added.

Co-Authored-By: Claude <noreply@anthropic.com>

The eight ReadForeign/WriteForeign path instances follow the type: pathy
stops existing and Path lives in Erl.Kernel.Filename, which this package
already depends on. So they port rather than being deleted, and the
pathy dependency -- which this package imported without declaring until
erl-kernel stopped supplying it -- goes.

The pair is symmetric now. It was not: printing needed a sandbox, so a
field was read as a bare Path and written as a SandboxedPath, and no
single type ever round-tripped. That asymmetry was the sandbox tax
reaching the serialization layer, and it goes with the sandbox.

Two consequences for a reader of these instances, both from the parsers
rather than from here. ReadForeign AbsDir accepts "/a/b" now -- a
trailing slash asserts Dir and its absence asserts nothing -- where the
old parser demanded the slash and so rejected most directory strings
anyone would put in a JSON document. And a document carrying ".." in a
path field is now rejected rather than silently normalised.

Does not build until erl-kernel is pushed and the ref here is bumped;
the local build is against a path: override that is deliberately not
committed.

The two commits before this one do not build against the erl-kernel the
ref pointed at; they were written against a local path: override while
erl-kernel was unpublished. 278b2b4 is v1.0.0, so the override goes and
the ref moves.

The declared dependency list moves with it. A git extra_package has to
restate the remote package's dependencies here, and erl-kernel v1.0.0
gained erl-maps, erl-modules, ordered-collections and strings.

Verified: spago build, clean, against the published SHA. `spago test`
fails at Test.Main's second assertion, but it fails identically on an
untouched master worktree -- pre-existing, and nothing to do with the
path instances.

650684b's message claims `spago test` fails at Test.Main's second
assertion and calls that failure pre-existing. Both halves are wrong.
The suite passes. What fails is bare `spago test`, which is not how this
repository is tested -- the Makefile runs `rebar3 compile` first, and
that is what puts jsx on the code path.

The message is wrong in a way worth recording rather than quietly
dropping, because the mistake was not carelessness about the invocation.
`_parseJSON` calls `jsx:decode/2`; a missing jsx raises `undef`; and
`parseJSON` catches exceptions into a `Left`. So an absent erlang
dependency is reported several frames away as `Expected: true / Actual:
false` -- an assertion failure, with nothing in it about jsx. Running the
same wrong invocation against an untouched master reproduced the same
wrong answer, which looked like proof that the failure predated the
change and was in fact only proof that the invocation was wrong in both
places.

An error is not a result. A runner that cannot reach its dependencies
answers with something shaped like a verdict.

Nothing about the path instances in 650684b changes; only the claim in
its message about how they were verified. They are verified now, by the
suite, run properly.