Futher cleans up store object info JSON v2

Since we haven't released v2 yet (2.32 has v1) we can just update this
in-place and avoid version churn.

Note that as a nice side effect of using the standard `Hash` JSON impl,
we don't neeed this `hashFormat` parameter anymore.

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

@@ -22,6 +22,14 @@ The store path info JSON format has been updated from version 1 to version 2:
   - New: `"ca": {"method": "nar", "hash": {"algorithm": "sha256", "format": "base64", "hash": "EMIJ+giQ..."}}`
   - Still `null` values for input-addressed store objects
 
+- **Structured hash fields**:
+
+  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..."}`
+  - Same structure applies to `downloadHash` in NAR info contexts
+
 Nix currently only produces, and doesn't consume this format.
 
 **Affected command**: `nix path-info --json`

doc/manual/source/protocols/json/schema/store-object-info-v2.yaml

@@ -71,7 +71,7 @@ $defs:
           Note: This field may not be present in all contexts, such as when the path is used as the key and the the store object info the value in map.
 
       narHash:
-        type: string
+        "$ref": "./hash-v1.yaml"
         title: NAR Hash
         description: |
           Hash of the [file system object](@docroot@/store/file-system-object.md) part of the store object when serialized as a [Nix Archive](@docroot@/store/file-system-object/content-address.md#serial-nix-archive).
@@ -229,7 +229,7 @@ $defs:
           > This is an impure "`.narinfo`" field that may not be included in certain contexts.
 
       downloadHash:
-        type: string
+        "$ref": "./hash-v1.yaml"
         title: Download Hash
         description: |
           A digest for the compressed archive itself, as opposed to the data contained within.