sbase 0.1.3: it names the C library that answers openkal-linux#13

[Sunrisepeak]

Third and last of the set that follows
#271 and
#272.

⚠️ This one exists because a version requirement here is exact. Measured in a
sandbox after openkal-musl 0.6.0 was published — a manifest saying
openkal-musl = "0.5.0" still resolves to 0.5.0:

c-abi   musl   (openkal-musl@0.5.0, graph)

Nothing floats up, which is the property that keeps a release from moving under
a consumer that did not ask for it. The consequence is that a package does not
receive a fix by having one published beneath it — so every consumer pinned to
the old version needs a change of its own, and sbase was the one left.

⚠️ And its CI could not have told anyone: this ecosystem's workflows substitute
the provider's working tree for the version their manifests name, so
sbase's runs have been green against 0.6.0's content since that merged, while
what a consumer resolving sbase got was 0.5.0. Green CI and what a consumer
receives were opposite here.

What it now receives

Two of 0.6.0's three answers are reachable from these tools without any of them
doing anything unusual — xargs and sh start programs, and the suite is run by
a harness that reads what each tool wrote:

• a caller that redirects a standard stream and then starts a program had the
  started program write to the stream the caller had been started with;
• abort did not end the program, so an assertion failure reported a
  segmentation fault.

97 tools, sources unmodified, green against openkal-musl main (dispatched after
that merge). The digest is of the archive GitHub serves; the CN asset is that
same file, compared byte for byte: 87a58232…, 184678 bytes.