prettier: re-format

The latest prettier (3.6.1) seems to have slightly different
formatting for lists.  Re-run prettier and check in the results.

Change-Id: I6bee4bcee3677f6188a3fe4b89cd8846d96c11c4
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
diff --git a/CHANGELOG.md b/CHANGELOG.md
index dc34602..26a9ac8 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -28,7 +28,6 @@
 ### Removed
 
 - Previously deprecated symbols:
-
   - `crc32()`: Users must switch to `pldm_edac_crc32()`
   - `crc8()`: Users must switch to `pldm_edac_crc8()`
 
@@ -95,7 +94,6 @@
 - requester: Remove related deprecated APIs
 
   Remove all of:
-
   - `pldm_close()`
   - `pldm_open()`
   - `pldm_recv()`
@@ -150,7 +148,6 @@
 
 - Returned error values for the following stable APIs have changed their
   semantics:
-
   - `decode_descriptor_type_length_value()`
   - `decode_event_message_buffer_size_resp()`
   - `decode_get_numeric_effecter_value_resp()`
@@ -166,7 +163,6 @@
   association PDR creation
 
 - Register allocation changed for the following APIs:
-
   - `encode_get_downstream_firmware_parameters_req()`
   - `encode_get_state_effecter_states_resp()`
   - `encode_oem_meta_file_io_read_resp()`
@@ -248,7 +244,6 @@
 
 - Register assignment for parameters of a number of APIs changed with increased
   scrutiny on their implementations.
-
   - `decode_entity_auxiliary_names_pdr()`
   - `decode_get_state_sensor_readings_resp()`
   - `decode_oem_meta_file_io_req()`
@@ -280,7 +275,6 @@
   function to make it safer.
 
   Modification:
-
   - The meaning of the returned result.
   - Change parameters from individual pointers to a struct.
   - Check the length provided in the message won't exceed the buffer.
@@ -293,9 +287,7 @@
 
 - The following APIs are deprecated as unsafe due to various unfixable CWE
   violations:
-
   - [CWE-129: Improper Validation of Array Index](https://cwe.mitre.org/data/definitions/129.html)
-
     - `encode_get_bios_current_value_by_handle_resp()`
     - `encode_get_bios_table_resp()`
     - `encode_get_file_table_resp()`
@@ -311,11 +303,9 @@
     - `pldm_bios_table_string_find_by_string()`
 
   - [CWE-617: Reachable Assertion](https://cwe.mitre.org/data/definitions/617.html)
-
     - `pldm_entity_association_tree_copy_root()`
 
   - [CWE-789: Memory Allocation with Excessive Size Value](https://cwe.mitre.org/data/definitions/789.html)
-
     - `decode_oem_meta_file_io_req()`
 
   - [CWE-823: Use of Out-of-range Pointer Offset](https://cwe.mitre.org/data/definitions/823.html)
@@ -326,7 +316,6 @@
 ### Removed
 
 - Deprecated functions with the `_check` suffix
-
   - `get_fru_record_by_option_check()`
   - `pldm_bios_table_append_pad_checksum_check()`
   - `pldm_bios_table_attr_entry_enum_decode_def_num_check()`
@@ -439,7 +428,6 @@
   and the [clang-rename][] configurations under `evolutions/`
 
   The deprecated functions:
-
   - `get_fru_record_by_option_check()`
   - `pldm_bios_table_append_pad_checksum_check()`
   - `pldm_bios_table_attr_entry_enum_decode_def_num_check()`
@@ -550,16 +538,13 @@
 - transport: Stabilise core transport and implementation APIs
 
   This stabilisation covers the following headers and functions:
-
   - libpldm/transport.h
-
     - pldm_transport_poll()
     - pldm_transport_send_msg()
     - pldm_transport_recv_msg()
     - pldm_transport_send_recv_msg()
 
   - libpldm/transport/af-mctp.h
-
     - pldm_transport_af_mctp_init()
     - pldm_transport_af_mctp_destroy()
     - pldm_transport_af_mctp_core()
@@ -579,7 +564,6 @@
 
 - All the existing "requester" APIs from `libpldm/pldm.h` (also known as
   `libpldm/requester/pldm.h`):
-
   - pldm_open()
   - pldm_send_recv()
   - pldm_send()
@@ -694,7 +678,6 @@
   function. For APIs meeting this definition we define a precondition that
   struct pointers must point to valid objects to avoid polluting the function
   prototypes. The following APIs now have this precondition explicitly defined:
-
   - pldm_entity_extract()
   - pldm_entity_get_parent()
   - pldm_entity_is_exist_parent()
@@ -790,7 +773,6 @@
 ### Removed
 
 - bios_table: Remove deprecated APIs sanitized by assert():
-
   - pldm_bios_table_string_entry_encode()
   - pldm_bios_table_string_entry_decode_string()
   - pldm_bios_table_attr_entry_enum_encode()
@@ -848,7 +830,6 @@
   C provides enough foot-guns without us encoding them into library APIs.
   Specifically, deprecate the following in favour of their `*_check()` variants
   which ensure assertions won't fail or otherwise invoke UB:
-
   - pldm_bios_table_string_entry_encode()
   - pldm_bios_table_string_entry_decode_string()
   - pldm_bios_table_attr_entry_enum_encode()
diff --git a/docs/checklists/changes.md b/docs/checklists/changes.md
index dc29cf4..73c74d1 100644
--- a/docs/checklists/changes.md
+++ b/docs/checklists/changes.md
@@ -103,7 +103,6 @@
   APIs (see error condition).
 
 - Corollaries of the above two points:
-
   - Incorrect use of public API functions is always an error condition, and is
     dealt with by returning an error code.
 
@@ -233,7 +232,6 @@
 - [ ] All publicly exposed macros, types and functions relating to the PLDM
       specifications must be prefixed with either `pldm_` or `PLDM_` as
       appropriate
-
   - The only (temporary) exception are the `encode_*()` and `decode_*()`
     function symbols
 
@@ -250,12 +248,10 @@
 
 - [ ] If I've added support for a new PLDM message type, then I've defined both
       the encoder and decoder for that message.
-
   - This applies for both request _and_ response message types.
 
 - [ ] I've designed my APIs so their implementation does not require heap
       allocation.
-
   - Prefer [defining iterators][libpldm-iterator] over the message buffer to
     extract sub-structures from variable-length messages. Iterators avoid both
     requiring heap allocation in the implementation or splitting the API to
@@ -267,7 +263,6 @@
 
 - [ ] My new public message codec functions take a `struct` representing the
       message as a parameter
-
   - Function prototypes must _not_ decompose the message to individual
     parameters. This approach is not ergonomic and is difficult to make
     type-safe. This is especially true for message decoding functions which must
@@ -282,7 +277,6 @@
 
 - [ ] My new public `struct` definitions do _not_ define a flexible array
       member, unless:
-
   - [ ] It's contained in an `#ifndef __cplusplus` macro guard, as flexible
         arrays are not specified by C++, and
 
@@ -290,7 +284,6 @@
         accessed from C++, and
 
   - [ ] It is defined as per the C17 specification by omitting the length[^1]
-
     - Note: Any array defined with length 1 is _not_ a flexible array, and any
       access beyond the first element invokes undefined behaviour in both C and
       C++.
@@ -322,13 +315,11 @@
 
 - [ ] I have not used `assert()` to evaluate any error conditions without also
       handling the error condition by returning an error code the the caller.
-
   - Release builds of the library are configured with `assert()` disabled
     (`-Db_ndebug=if-release`, which provides `-DNDEBUG` in `CFLAGS`).
 
 - [ ] My new APIs return negative `errno` values on error and not PLDM
       completion codes.
-
   - [ ] The specific error values my function returns and their meaning in the
         context of the function call are listed in the API documentation.
 
@@ -340,12 +331,10 @@
 
 - [ ] I've used `goto` to clean up resources acquired prior to encountering an
       error condition
-
   - Replication of resource cleanup across multiple error paths is error-prone,
     especially when multiple, dependent resources have been acquired.
 
 - [ ] I've released acquired resources in stack-order
-
   - This should be the case regardless of whether we're in the happy path at the
     end of object lifetime or an error path during construction.
 
@@ -364,7 +353,6 @@
 
 - [ ] If I've added support for a new message type, then my commit message
       specifies all of:
-
   - [ ] The relevant DMTF specification by its DSP number and title
   - [ ] The relevant version of the specification
   - [ ] The section of the specification that defines the message type
@@ -445,13 +433,11 @@
 
 - [ ] If the function is marked `LIBPLDM_ABI_STABLE`, then I have changed the
       annotation to `LIBPLDM_ABI_DEPRECATED` and left it in-place.
-
   - [ ] I have updated the ABI dump, or will mark the change as WIP until it has
         been.
 
 - [ ] If the function is marked `LIBPLDM_ABI_DEPRECATED`, then I have removed it
       only after satisfying myself that each of the following is true:
-
   - [ ] There are no known users of the function left in the community
   - [ ] There has been at least one tagged release of `libpldm` subsequent to
         the API being marked deprecated
diff --git a/docs/checklists/releases.md b/docs/checklists/releases.md
index d1e5d93..bf9956a 100644
--- a/docs/checklists/releases.md
+++ b/docs/checklists/releases.md
@@ -7,7 +7,6 @@
 ## ABI
 
 - [ ] Generate the ABI dump for the release
-
   - This must be done from a shell session inside the OpenBMC CI Docker
     container for consistency