docs(specs): let S22's shadow table serve both recompute levels

What

Corrects the S22 spec on which table the repository-level size_bytes recompute joins, and follows the correction through the two sentences that scoped the shadow table to namespace-level use only.

The Reconciliation table's repositories.size_bytes row gave the join target as blob_storage_blobs while citing ADR-007's query as "reused as-is". That query joins blob_storage_blobs_by_namespace, as do ADR-007's other two repository-level example queries. Naming the shadow makes the citation true.

Why the shadow rather than the base table

blob_storage_blobs is partitioned by HASH(sha256). The repository-level recompute's digests are runtime values from the artifact walk, so nothing prunes: every lookup scatters across all 64 partitions. namespace_id is a literal in the same query, so the shadow prunes to exactly one partition before execution.

The two sentences that said otherwise are restated rather than deleted, because each was carrying an argument worth keeping:

• The Data Model's "existing solely to turn namespace-level reconciliation's SUM(size) … into a single-partition index-only scan" now names both reads and says why neither can prune the base table.
• Reconciliation's "S22 does not adopt ADR-007's Option A … the shadow serves the namespace-level recompute exclusively" keeps the Option A rejection and gives it a reason that survives the change: Option A leaves the base table partitioned by HASH(sha256), so it helps neither read.

One substantive change, not a correction

The shadow's primary key gains INCLUDE (size).

The covering index on (namespace_id) INCLUDE (size) answers the namespace-level SUM(size) index-only, and cannot serve the repository-level join at all — sha256 is neither a key nor an included column in it. Those lookups go through the primary key, so without INCLUDE (size) every matched digest costs a heap fetch, and the "single-partition index-only scan" the table was justified by holds for one of its two reads.

Reviewers who would rather accept the heap fetches should say so: dropping this leaves the other five edits standing.

ADR-007 carries the same index change in handbook!20699, which should merge first — it is the authority for this table's index set, and it also carries the "index-only" claim this MR corrects.

Related to #515