docs(changelog): close 0.1.0 for release

Author: danielebarbaro

CHANGELOG.md

@@ -7,22 +7,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## Unreleased
 
-### Added
-
-- The test suite runs against MySQL 8.4 and PostgreSQL 17 on every build, alongside the
-  SQLite matrix. `DB_DRIVER` points it at a server locally.
-
-### Fixed
-
-- `getCustomFields()` and the generated filters and sorts come back ordered by
-  `sort_order` and then by slug. The order was whatever the database returned, so the same
-  code gave a different order on SQLite and on a server, and the `sort_order` column was
-  never read.
-- A `decimal` value reads back the same on every driver. MySQL and PostgreSQL return the
-  full scale of the column, so a stored `12.5` came back as `12.500000` while SQLite gave
-  `12.5`.
-
-## 0.1.0 - 2026-09-07
+## 0.1.0 - 2026-09-08
 
 First public release.
 
@@ -65,6 +50,8 @@ First public release.
 - Model factories for both package models.
 - A README covering installation, configuration, the field type table, the query
   operations, the events, the exceptions, the form metadata and the test commands.
+- The test suite runs against MySQL 8.4 and PostgreSQL 17 on every build, alongside the
+  SQLite matrix. `DB_DRIVER` points it at a server locally.
 
 ### Changed
 
@@ -130,3 +117,10 @@ First public release.
 - The test suite pins an in memory database, so `composer build` followed by
   `composer test` no longer fails on the migrations that `workbench:build` publishes into
   the Testbench skeleton.
+- `getCustomFields()` and the generated filters and sorts come back ordered by
+  `sort_order` and then by slug. The order was whatever the database returned, so the same
+  code gave a different order on SQLite and on a server, and the `sort_order` column was
+  never read.
+- A `decimal` value reads back the same on every driver. MySQL and PostgreSQL return the
+  full scale of the column, so a stored `12.5` came back as `12.500000` while SQLite gave
+  `12.5`.