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/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