openkal-llvm-runtime 0.3.1: it names the C library that answers openkal-linux#13

[Sunrisepeak]

Follows #271, which carried
openkal-musl 0.6.0.

Nothing in this package changes. 0.3.0 → 0.3.1 records which C library a
consumer resolving that version is handed, and the reason is this package's
business directly: libc++abi's terminate handler ends in abort, and until
openkal-musl 0.6.0 abort did not end the program — musl's raise is tkill,
the port had no case for it, so abort fell through to a_crash() and every
uncaught C++ exception over this runtime reported a segmentation fault.

Verification

• Five jobs green on main, including the bare-metal cfg(os = "none")
  configuration — the only place that compiles the C library with
  OKM_HAS_FS=0 and OKM_HAS_PROCESS=0.

• The pair was validated together before either was released:
  tools/branch-graph.sh prefers a branch of the same name in each repository,
  and openkal-musl had one, so the run built that pull request's working tree
  rather than a version that was not yet here.

• openkal-musl 0.6.0, resolved from this index in a sandbox holding none of
  these packages, builds a program and answers all three:

  c-abi             musl           (openkal-musl@0.6.0, graph)
  redirection reaches the started program: true
  abort is SIGABRT: true (status 0x6)
  WNOHANG returns while it runs: true, then names it: true
  

• mcpplibs/sbase — 97 suckless tools above this C library, sources
  unmodified — green against openkal-musl main.

The digest is of the archive GitHub serves; the CN asset is that same file,
downloaded from the mirror and compared: 8782c19e… both ways, 15613758 bytes.