📝 Add development/ docs for decisions and known issues

Category files under development/ replace the decision prose that was
scattered through README.md and CONTRIBUTING.md. Each decision is a block with
Decision (YYYY-MM) / Why / Rejected / Known issue; the new library.md records
the public API contract and its limitations. AGENTS.md and backlog.tasks now
point at the new home.

backlog.tasks

@@ -27,12 +27,18 @@ Documentation:
 ☐ Clean up CONTRIBUTING.md and README.md, create docs
     ☐ Review existing documentation for accuracy and completeness
     ☐ README.md should be the main entry point for users, and CONTRIBUTING.md should be the main entry point for contributors
-    ☐ A lot of decisions are documented in the current README.md and CONTRIBUTING.md, that are not part of a main entry for users, how to use the library nor part of a main entry for contributors,
-        ☐ evaluate a new structure for the docs, and move the relevant information to the new docs
+    ☐ Move the decisions, shortcomings and known issues out of README.md and CONTRIBUTING.md
+        ☐ Decided: category files under development/ (one per area), not ADRs. Each decision is a block with #### Decision (YYYY-MM) / #### Why / #### Rejected / #### Known issue; rationale in development/README.md
         ☐ have a look at other well known repositories for inspiration on how to structure the docs
         ☐ often times a docs folder is used, but this usually contains further user of the library documentation, that is deployed to a website. Deployment is out of scope for now
-        ☐ More important is to have the documentation of our decisions, shortcomings and known issues, not sure where to put this. at work we have ADRs, maybe that? Please suggest something after having looked at other well known repos
         ☐ make sure to preserve that information in the new docs
+        ☐ development/README.md - index and decision-block convention
+        ☐ development/workflow.md - branching, script prefixes, feedback tiers, commits
+        ☐ development/tooling.md - toolchain decisions and editor setup
+        ☐ development/testing.md - type-driven testing
+        ☐ development/ci.md - pipeline, runner image, coverage serving
+        ☐ development/publishing.md - release and npm publishing
+        ☐ development/library.md - public API design and its limitations
     ☐ README.md
         ☐ I really like the order perl documentation does it: name with a single line description, version, Synopsis, Description, examples, API reference, license
             (example: https://metacpan.org/pod/Scalar::Util)
@@ -75,7 +81,7 @@ Maintenance:
     ✔ Log tool-cache state from the job container to find it (temporary, removed once understood) @done
     ✔ Guard the invariant in CI (`Assert the baked tool cache is present`) @done
 ✘ Enable force-pull for the runner so a changed act-ci image is never missed @low @cancelled
-    → decided against: it is acceptable to miss a runner-side image change, and the image is only rebuilt on a Node bump, which changes the tag anyway. A Dockerfile-only change re-pushed under an unchanged tag is a known issue with a manual `docker rmi` workaround (see CONTRIBUTING § CI runner image).
+    → decided against: it is acceptable to miss a runner-side image change, and the image is only rebuilt on a Node bump, which changes the tag anyway. A Dockerfile-only change re-pushed under an unchanged tag is a known issue with a manual `docker rmi` workaround (see development/ci.md).
 ✔ Improve CI publish @done
     ✔ Check whether publish job is only run on tags, if not, guard it @done
     ✔ Gate only single steps @done