Docs: Fix rendering lists

format/puffin-spec.md

@@ -145,6 +145,7 @@ sub-position) are tested for inclusion in the bitmap. If a bitmap is not found
 for the key, then it is not set.
 
 The serialized blob contains:
+
 * Combined length of the vector and magic bytes stored as 4 bytes, big-endian
 * A 4-byte magic sequence, `D1 D3 39 64`
 * The vector, serialized as described below

format/spec.md

@@ -262,6 +262,7 @@ Iceberg's Avro manifest format does not store the type of lower and upper bounds
 | `decimal(P, S)`  | _any_            | `decimal(P', S)`; `P' <= P` |
 
 Type promotion is not allowed for a field that is referenced by `source-id` or `source-ids` of a partition field if the partition transform would produce a different value after promoting the type. For example, `bucket[N]` produces different hash values for `34` and `"34"` (2017239379 != -427558391) but the same value for `34` and `34L`; when an `int` field is the source for a bucket partition field, it may be promoted to `long` but not to `string`. This may happen for the following type promotion cases:
+
 * `date` to `timestamp` or `timestamp_ns`
 
 Any struct, including a top-level schema, can evolve through deleting fields, adding new fields, renaming existing fields, reordering existing fields, or promoting a primitive using the valid type promotions. Adding a new field assigns a new ID for that field and for any nested fields. Renaming an existing field must change the name, but not the field ID. Deleting a field removes it from the current schema. Field deletion cannot be rolled back unless the field was nullable or if the current snapshot has not changed.
@@ -1001,6 +1002,7 @@ Notes:
 This section details how to encode row-level deletes in Iceberg delete files. Row-level deletes are added by v2 and are not supported in v1. Deletion vectors are added in v3 and are not supported in v2 or earlier. Position delete files must not be added to v3 tables, but existing position delete files are valid.
 
 There are three types of row-level deletes:
+
 * Deletion vectors (DVs) identify deleted rows within a single referenced data file by position in a bitmap
 * Position delete files identify deleted rows by file location and row position (**deprecated**)
 * Equality delete files identify deleted rows by the value of one or more columns

format/view-spec.md

@@ -65,6 +65,7 @@ The view version metadata file has the following fields:
 | _optional_  | `properties`         | A string to string map of view properties [2] |
 
 Notes:
+
 1. The number of versions to retain is controlled by the table property: `version.history.num-entries`.
 2. Properties are used for metadata such as `comment` and for settings that affect view maintenance. This is not intended to be used for arbitrary metadata.
 
@@ -102,6 +103,7 @@ A view version can have more than one representation. All representations for a
 View versions are immutable. Once a version is created, it cannot be changed. This means that representations for a version cannot be changed. If a view definition changes (or new representations are to be added), a new version must be created.
 
 Each representation is an object with at least one common field, `type`, that is one of the following:
+
 * `sql`: a SQL SELECT statement that defines the view
 
 Representations further define metadata for each type.