Version the library at 0.1.0

project() now carries VERSION 0.1.0, and is the single place a version number
is spelled. It flows into generated version macros, the shared library's
VERSION/SOVERSION, the Version: field in akstdlib.pc, and a new
akstdlibConfigVersion.cmake. Before this @PROJECT_VERSION@ expanded to
nothing, so akstdlib.pc shipped an empty Version: and libakstdlib.so carried
no soname at all.

0.x on purpose: TODO.md section 2.1 still records four confirmed defects whose
fixes change documented behaviour, so the API is not being promised yet. While
the major version is 0 the soname carries MAJOR.MINOR -- 0.1 and 0.2 are
different ABIs -- and becomes MAJOR alone at 1.0. The if() in CMakeLists.txt
and the #if in tests/test_version.c encode that rule and are tested against
each other.

include/akstdlib_version.h.in is configured into the build tree as
akstdlib_version.h and installed beside akstdlib.h. It defines
AKSL_VERSION_MAJOR/MINOR/PATCH/STRING/NUMBER and AKSL_VERSION_SONAME.
AKSL_VERSION_NUMBER is computed rather than written as a literal, because a
literal 000100 is octal in C and would make 0.1.0 compare as 64;
test_version.c asserts it against the runtime components, so a rewrite to a
literal fails.

Those macros record what a caller was compiled against. aksl_version(),
aksl_version_string() and aksl_version_soname() report what actually loaded,
and AKSL_VERSION_CHECK() compares the two, raising AKERR_VALUE naming both.
It is a macro so that it expands at the caller's site and captures the
caller's numbers; the function compares them against the ones baked into the
library. Compatibility is "same soname", so patch is ignored -- a caller built
against 0.1.0 keeps working against 0.1.7.

Normally the soname catches a mismatch at load time and the check never fires.
It earns its keep when the soname is bypassed: a 0.2.0 build dropped in under
the 0.1 filename loads happily, and only the check notices.

write_basic_package_version_file() uses SameMinorVersion to mirror the soname,
falling back to ExactVersion below CMake 3.11 where that mode does not exist.
The fallback is stricter than the soname rule -- it pins the patch level too --
but never laxer, and wrongly refusing a good pairing beats wrongly accepting a
bad one.

Coverage of src/stdlib.c rose to 99.1% of lines (217/219), 45.1% of branches
and 25/25 functions. That puts branch coverage back over the old 45 gate, but
the gate stays at 40: 0.1 points of headroom is not a ratchet.

ctest 14/14, ASan+UBSan 14/14, coverage 16/16 at 90/40. Also verified out of
tree: SONAME libakstdlib.so.0.1 recorded in consumers, pkg-config
--modversion reporting 0.1.0, find_package(akstdlib 0.1) accepted with 0.2 and
1.0 refused, a patch-bumped 0.1.1 loading and passing the check, a 0.2.0
dropped in under the 0.1 filename caught by it, and an embedded
add_subdirectory build keeping its own version rather than the parent's.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -25,6 +25,70 @@ A top-level build compiles the vendored `deps/libakerror`. When `libakstdlib` is
 consumed as a subproject, it uses whatever `akerror::akerror` target or installed
 package the parent provides instead.
 
+### This library's own version
+
+`libakstdlib` is at **0.1.0**. The version lives in exactly one place — the
+`project()` call in `CMakeLists.txt` — and flows from there into everything
+else, so a bump is a one-line edit:
+
+| Artifact | Value at 0.1.0 | From |
+| --- | --- | --- |
+| `AKSL_VERSION_MAJOR` / `_MINOR` / `_PATCH` | `0` / `1` / `0` | `include/akstdlib_version.h.in` |
+| `AKSL_VERSION_STRING` | `"0.1.0"` | same |
+| `AKSL_VERSION_NUMBER` | `100` | same |
+| `AKSL_VERSION_SONAME` | `"0.1"` | same |
+| shared library | `libakstdlib.so.0.1.0`, soname `libakstdlib.so.0.1` | `VERSION` / `SOVERSION` |
+| `pkg-config --modversion akstdlib` | `0.1.0` | `akstdlib.pc` |
+| `find_package(akstdlib 0.1)` | accepted; `0.2` and `1.0` refused | `akstdlibConfigVersion.cmake` |
+
+`akstdlib_version.h` is **generated** — that is why there is no such file in the
+source tree, only the `.in` template beside `akstdlib.h`. Don't hand-edit the
+copy in your build directory; change the template or `project()`.
+
+It is `0.x` deliberately. `TODO.md` §2.1 still records four confirmed defects
+whose fixes change documented behaviour, so the API is not being promised yet.
+While the major version is `0`, **the soname carries `MAJOR.MINOR`**: 0.1 and 0.2
+are different ABIs and the loader will not substitute one for the other. At 1.0
+the soname becomes `MAJOR` alone — the `if(PROJECT_VERSION_MAJOR EQUAL 0)` in
+`CMakeLists.txt` and the matching `#if` in `tests/test_version.c` are the two
+places that encode this, and they are tested against each other.
+
+`AKSL_VERSION_NUMBER` is computed rather than written as a literal, because a
+literal `000100` is *octal* in C and would make 0.1.0 compare as 64.
+
+#### Compiled-against vs. loaded
+
+The macros above record what a caller was **compiled** against. What it actually
+**loaded** is a different question, and the two can disagree:
+
+```c
+int major, minor, patch;
+akerr_ErrorContext *e = aksl_version(&major, &minor, &patch);  /* the loaded .so */
+const char *v = aksl_version_string();                         /* likewise */
+
+e = AKSL_VERSION_CHECK();   /* compares the two; AKERR_VALUE on a mismatch */
+```
+
+`AKSL_VERSION_CHECK()` is a macro on purpose: it expands at *your* call site, so
+it captures the `AKSL_VERSION_*` you were built with and passes them to a
+function that compares against the values baked into the library. Calling
+`aksl_version_check()` with hand-written numbers defeats the whole mechanism.
+
+Compatibility is defined as "same soname", so pre-1.0 both major and minor must
+match and the patch level is ignored — a caller built against 0.1.0 keeps working
+against 0.1.7, which is exactly the promise the shared soname makes.
+
+In normal use the soname catches the mismatch first, at load time, and the check
+never fires. It earns its keep when the soname is bypassed: a hand-install that
+drops a 0.2.0 build in under the 0.1 filename, or a package that strips
+versioning. Then the loader is happy and only the check notices:
+
+```
+compiled against : 0.1.0 (soname 0.1)
+loaded           : 0.2.0 (0.2.0)
+MISMATCH DETECTED: compiled against libakstdlib 0.1.0, loaded 0.2.0 (soname 0.2)
+```
+
 ### The libakerror version floor
 
 **libakerror 1.0.0 or newer is required.** That release made the status-name
@@ -182,8 +246,8 @@ cmake -S . -B build-coverage -DAKSL_COVERAGE=ON \
       -DAKSL_COVERAGE_THRESHOLD=90 -DAKSL_COVERAGE_BRANCH_THRESHOLD=40
 ```
 
-**Where it stands.** `src/stdlib.c` is at **99.0% of lines (200/202)**, **44.3% of
-branches (481/1087)** and **21/21 functions**, so 90/40 above is a ratchet with
+**Where it stands.** `src/stdlib.c` is at **99.1% of lines (217/219)**, **45.1% of
+branches (519/1151)** and **25/25 functions**, so 90/40 above is a ratchet with
 headroom rather than a target. The two uncovered lines are both
 `} HANDLE(e, AKERR_ITERATOR_BREAK) {` — in libakerror that macro begins with the
 `break;` belonging to `PROCESS`'s `case 0:` arm, which is only reachable when a
@@ -197,8 +261,10 @@ stack-trace buffer limits, `akerr_valid_error_address` failures — and belong t
 libakerror's own suite rather than to this one. The libakerror 1.0.0 bump made
 that gap wider without changing a line of this library: the branch denominator
 went from 661 to 1087 as those macros grew, so the same tests that scored 51.0%
-(337/661) now score 44.3% (481/1087). The gate moved 45 → 40 to match; line and
-function coverage did not move at all.
+(337/661) dropped to 44.3% (481/1087). The gate moved 45 → 40 to match; line and
+function coverage did not move at all. Adding the `aksl_version_*` family and its
+tests brought the figure back to 45.1% (519/1151), but the gate stays at 40 —
+0.1 points of headroom is not a ratchet.
 
 Two caveats. Coverage is measured at `-O0`, because the optimizer reorders lines
 until per-line counts stop matching the source — so a coverage build is not the