JSON for Hash now has to be Base16

Fix #14532.

As discussed on the call today:

1. We'll stick with `format = "base16"` and `hash = "<hash>"`, not do
   `base16 = "<hash>"`, in order to be forward compatible with
   supporting more versioning formats.

   The motivation we discussed for someday *possibly* doing this is
   making it easier to write very slap-dash lang2nix tools that create
   (not consume) derivations with dynamic derivations.

2. We will remove support for non-base16 (and make that the default, not
   base64) in `Hash`, so this is strictly forward contingency, *not*
   yet something we support. (And also not something we have concrete
   plans to start supporting.)

doc/manual/rl-next/json-format-changes.md

@@ -19,7 +19,7 @@ The store path info JSON format has been updated from version 1 to version 2:
   Content address is now a structured JSON object instead of a string:
 
   - Old: `"ca": "fixed:r:sha256:1abc..."`
-  - New: `"ca": {"method": "nar", "hash": {"algorithm": "sha256", "format": "base64", "hash": "EMIJ+giQ..."}}`
+  - New: `"ca": {"method": "nar", "hash": {"algorithm": "sha256", "format": "base16", "hash": "10c209fa..."}}`
   - Still `null` values for input-addressed store objects
 
 - **Structured hash fields**:
@@ -27,8 +27,9 @@ The store path info JSON format has been updated from version 1 to version 2:
   Hash values (`narHash` and `downloadHash`) are now structured JSON objects instead of strings:
 
   - Old: `"narHash": "sha256:FePFYIlMuycIXPZbWi7LGEiMmZSX9FMbaQenWBzm1Sc="`
-  - New: `"narHash": {"algorithm": "sha256", "format": "base64", "hash": "FePFYIlM..."}`
+  - New: `"narHash": {"algorithm": "sha256", "format": "base16", "hash": "15e3c5608946..."}`
   - Same structure applies to `downloadHash` in NAR info contexts
+  - The `format` field is always `"base16"` (hexadecimal)
 
 Nix currently only produces, and doesn't consume this format.
 
@@ -48,8 +49,8 @@ The derivation JSON format has been updated from version 3 to version 4:
 - **Consistent content addresses**:
 
   Floating content-addressed outputs now use structured JSON format.
-  This is the same format as `ca` in in store path info (after the new version).
+  This is the same format as `ca` in store path info (after the new version).
 
 Version 3 and earlier formats are *not* accepted when reading.
 
-**Affected command**: `nix derivation`, namely it's `show` and `add` sub-commands.
+**Affected command**: `nix derivation`, namely its `show` and `add` sub-commands.

doc/manual/source/protocols/json/hash.md

@@ -2,28 +2,16 @@
 
 ## Examples
 
-### SHA-256 with Base64 encoding
-
-```json
-{{#include schema/hash-v1/sha256-base64.json}}
-```
-
-### SHA-256 with Base16 (hexadecimal) encoding
+### SHA-256
 
 ```json
 {{#include schema/hash-v1/sha256-base16.json}}
 ```
 
-### SHA-256 with Nix32 encoding
+### BLAKE3
 
 ```json
-{{#include schema/hash-v1/sha256-nix32.json}}
-```
-
-### BLAKE3 with Base64 encoding
-
-```json
-{{#include schema/hash-v1/blake3-base64.json}}
+{{#include schema/hash-v1/blake3-base16.json}}
 ```
 
 <!-- need to convert YAML to JSON first

doc/manual/source/protocols/json/schema/hash-v1.yaml

@@ -12,18 +12,14 @@ properties:
   format:
     type: string
     enum:
-    - base64
-    - nix32
     - base16
-    - sri
     title: Hash format
     description: |
       The encoding format of the hash value.
 
-      - `base64` uses standard Base64 encoding [RFC 4648, section 4](https://datatracker.ietf.org/doc/html/rfc4648#section-4)
-      - `nix32` is Nix-specific base-32 encoding
-      - `base16` is lowercase hexadecimal
-      - `sri` is the [Subresource Integrity format](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity).
+      `base16` (lowercase hexadecimal) is the only format that is currently supported for JSON serialization.
+      This field exists primarily to reduce ambiguity about what the hash means.
+      It would also help us support other formats in the future, but there are no concrete plans to do so at this.
   hash:
     type: string
     title: Hash