docs(specs): npm's deferrable constraint is S32's precedent

What this does

Corrects one stale claim in two places: that S32's deferrable unique constraint is the first in the shipped schema, with no in-repo precedent for a migration author to copy.

S31 shipped one first. unique_nvru_ns_id_repository_id_position on npm_virtual_repository_upstreams landed in internal/datastore/migrations/sql/20260828102654_create_npm_virtual_repository_upstreams.sql, and structure.sql carries it as the parent constraint plus its 64 partition clones — 65 DEFERRABLE lines, measured at ddfb0f545.

The two sites

## Data Model, the unique-constraint row. Now names that migration as the precedent to copy, and names the one thing not to copy from it: npm's position floor is 0 and this table's is 1.

## Acceptance Criteria, Step 2's first criterion. The clause is deleted rather than corrected. It justified the strict two-statement count by there being no precedent, and the count already stands on its own argument — a non-deferrable constraint plus a three-statement dance through a spare position also exchanges two rows in one transaction, so a criterion that does not fix the count cannot tell a deferred constraint from an immediate one.

Where this came from

The review of the ADR-007 container-virtual amendment (gitlab-com/content-sites/handbook!20928 (merged)) surfaced the same false claim in the ADR, where it is now corrected. The plan's ### Schema facts carries the matching fix in !2063 (merged), which names this MR as the one closing the spec side.

Scope

Two lines. No acceptance criterion is added, removed, or weakened, and no behavior the spec fixes changes.