Fix release notes for #10027 (#10510)

Breaking changes are supposed to be listed first in the release notes.
PR #10027 mistakenly did not list it's breaking changes first, so this
commit fixes that.

Author: jkosh44

doc/user/content/release-notes.md

@@ -107,6 +107,20 @@ These changes are present in [unstable builds](/versions/#unstable-builds) and
 are slated for inclusion in the next stable release. There may be additional
 changes that have not yet been documented.
 
+- **Breaking change.** Return an error when [`extract`](/sql/functions/extract/)
+  is called with a [`date`] value but a time-related field (e.g., `SECOND`).
+
+  Previous versions of Materialize would incorrectly return `0` in these cases.
+  The new behavior matches PostgreSQL.
+
+  [`date_part`](/sql/functions/date-part/) still returns a `0` in these cases,
+  which matches the PostgreSQL behavior {{% gh 9853 %}}.
+
+- **Breaking change.** Change the return type of [`extract`](/sql/functions/extract/)
+  from [`float`](/sql/types/float/) to [`numeric`](/sql/types/numeric/).
+
+  This new behavior matches PostgreSQL v14 {{% gh 9853 %}}.
+
 - Add the [`greatest`](/sql/functions/#generic) and [`least`](/sql/functions/#generic)
   functions.
 
@@ -120,20 +134,6 @@ changes that have not yet been documented.
 - Support the [`radians`](/sql/functions/#trigonometric-func) and
   [`degrees`](/sql/functions/#trigonometric-func) functions.
 
-- **Breaking change.** Return an error when [`extract`](/sql/functions/extract/)
-  is called with a [`date`] value but a time-related field (e.g., `SECOND`).
-
-  Previous versions of Materialize would incorrectly return `0` in these cases.
-  The new behavior matches PostgreSQL.
-
-  [`date_part`](/sql/functions/date-part/) still returns a `0` in these cases,
-  which matches the PostgreSQL behavior.
-
-- **Breaking change.** Change the return type of [`extract`](/sql/functions/extract/)
-  from [`float`](/sql/types/float/) to [`numeric`](/sql/types/numeric/).
-
-  This new behavior matches PostgreSQL v14.
-
 - Follow PostgreSQL's type conversion rules for the relations involved in a
   `UNION`, `EXCEPT`, or `INTERSECT` operation {{% gh 3331 %}}.