run `make fix`

js/docs/src/content/docs/video-metadata/c2pa-integration.md

···
 
 The actual metadata insertion and signing done to each video segment is through
 [C2PA](https://c2pa.org/) tooling. A
-[fork](https://github.com/streamplace/c2pa-rs) of their Rust
-SDK that adds support for ES256K is used, and called in Go through FFI. The code
-for this can be seen in `rust/iroh-streamplace/src/c2pa.rs`.
+[fork](https://github.com/streamplace/c2pa-rs) of their Rust SDK that adds
+support for ES256K is used, and called in Go through FFI. The code for this can
+be seen in `rust/iroh-streamplace/src/c2pa.rs`.
 
 The metadata stored in the video with C2PA must be in a valid C2PA "manifest"
 format, documented in the specification. Here is an example Streamplace
···
               "Iptc4xmpExt": "http://iptc.org/std/Iptc4xmpExt/2008-02-29/"
             },
             "dc:creator": "did:plc:y3lae7hmqiwyq7w2v3bcb2c2",
-            "dc:title": [
-              "🦎🦎"
-            ],
-            "dc:date": [
-              "2025-10-21T19:24:24.156Z"
-            ],
+            "dc:title": ["🦎🦎"],
+            "dc:date": ["2025-10-21T19:24:24.156Z"],
             "distributionPolicy": {
               "deleteAfter": "2025-10-21T19:29:24.000Z"
             },
···
 
 The official version of c2patool can extract this manifest, but will not
 consider it valid due to the use of ES256K. If you build c2patool from the
-[fork](https://github.com/streamplace/c2pa-rs) used by
-Streamplace, it will validate.
+[fork](https://github.com/streamplace/c2pa-rs) used by Streamplace, it will
+validate.
 
 Note the variety of information stored in the manifest: user DID, signing key,
 timestamp, content warnings, copyright, etc. More can be added in the future,
 for example whether you consent to remixing.
 
-You can see several assertions with the name `place.stream.*`. This is 
-where Streamplace-specific metadata is stored, and is related to the lexicon.
-It's the easiest place to parse out this metadata.
+You can see several assertions with the name `place.stream.*`. This is where
+Streamplace-specific metadata is stored, and is related to the lexicon. It's the
+easiest place to parse out this metadata.
 
-In addition to the primary `place.stream` assertions, we make a best-effort attempt to translate the Streamplace assertions into spec-compliant C2PA metadata assertions, which are also included in the signed manifest. This allows other C2PA-compliant software to parse out information about Streamplace segments, such as content warnings. However, not everything Streamplace does fits neatly into C2PA-compliant metadata, so the primary source of truth for metadata on a Streamplace segment remains the `place.stream` assertions.
+In addition to the primary `place.stream` assertions, we make a best-effort
+attempt to translate the Streamplace assertions into spec-compliant C2PA
+metadata assertions, which are also included in the signed manifest. This allows
+other C2PA-compliant software to parse out information about Streamplace
+segments, such as content warnings. However, not everything Streamplace does
+fits neatly into C2PA-compliant metadata, so the primary source of truth for
+metadata on a Streamplace segment remains the `place.stream` assertions.
 
 ## Code paths
 

js/docs/src/content/docs/video-metadata/metadata-record.md

···
    the
    [IPTC controlled vocabulary for content warnings](https://cv.iptc.org/newscodes/contentwarning/).
    Each warning provides descriptions to help creators properly categorize their
-   content. Streamplace node operators may also configure their nodes to exclude certain types of content.
+   content. Streamplace node operators may also configure their nodes to exclude
+   certain types of content.
 2. **Content Rights** (`place.stream.metadata.contentRights`): This section
    captures copyright and attribution information, including the creator’s name,
    copyright notice, publication year, license type, and credit line. The system
···
 3. **Distribution Policy** (`place.stream.metadata.distributionPolicy`): This
    section currently allows creators to specify a `deleteAfter` property, which
    is meant to indicate the time after which the user no longer wants the stream
-   to be made available for playback. It also allows you to optionally restrict syndication of your livestream to a certain set of broadcasters.
+   to be made available for playback. It also allows you to optionally restrict
+   syndication of your livestream to a certain set of broadcasters.
 
 When a user creates or updates their metadata configuration through the
 frontend, the record is published to their Personal Data Server (PDS) with the

js/docs/src/content/docs/video-metadata/signing.md

···
    and **distribution policy**. This record is also synced by nodes to their
    local database.
 5. **Stream Authentication**: When a user starts a stream, they include their
-   stream key as a param in the WHIP or RTMPS request to the node. The node decodes the
-   key, extracts the private key and DID, and verifies that the public key
-   exists and is valid.
+   stream key as a param in the WHIP or RTMPS request to the node. The node
+   decodes the key, extracts the private key and DID, and verifies that the
+   public key exists and is valid.
 6. **Signer Creation**: Once authenticated, the node creates a signer instance
    using the user's private key.
 7. **Segmentation**: The incoming live stream is segmented into one-second MP4
    chunks.
 8. **Manifest Creation and Signing**: For each segment, the node creates a C2PA
-   manifest using the user's metadata configuration. It then uses the streamer's private key to sign the manifest, and embeds the signed manifest directly into
-   the MP4 segment.
+   manifest using the user's metadata configuration. It then uses the streamer's
+   private key to sign the manifest, and embeds the signed manifest directly
+   into the MP4 segment.
 9. **Signed Segments**: The output is a continuous stream of MP4 segments, each
    cryptographically signed and containing its own C2PA manifest.