spec(9.4): permit 401 for profile_unreachable on a privileged request

[maoryeh]

§9.4 mandated 424 Failed Dependency. That is right where fetching a profile is an ordinary
server-side dependency — registry registration, say — and wrong for the §10.1.6 case, which is the
one most implementations will hit first.

Under §10.1.6 a fetchable profile is part of the agent header being an identity. A profile that
cannot be retrieved therefore leaves the request unauthenticated, not merely blocked on a
dependency. 401 is the more accurate answer and the more actionable one: what needs fixing is the
caller's own published document, and every client already has a 401 path.

Mandating 424 alone also had a practical cost worth naming. It is unreachable from a gRPC-based
stack, where HTTP statuses are derived from gRPC's closed set of status codes and nothing maps to
Failed Dependency. An implementation there has to either repoint a status mapping shared with every
other service on the platform, or pick some third status — and picking arbitrarily is precisely the
interoperability failure this table exists to prevent. A spec that cannot be conformed to gets
approximated instead.

So 424 stays, and 401 is permitted for the privileged-request case. This narrows the mapping rather
than replacing it.

Found while implementing §10.1.6: the status mapping was the one entry in the table that could not be
satisfied, and the fallback we had shipped was 401 anyway.

Checker: refs ok. schemas/vectors need jsonschema locally; authority reports the same pre-existing failures as clean master (no built site).

🤖 Generated with Claude Code

[maoryeh]

Rebased onto current master. §9.4 was rebuilt into three disjoint error families in the meantime and the four-column protocol-error table this originally edited is now a six-column matrix, so the change is re-authored rather than replayed — same substance, new shape.

Context for the second half of the rationale, which has since been verified rather than asserted: FAILED_PRECONDITION -> 428 and ABORTED -> 409 are the only near misses in the Wix gRPC status map, and all 17 gRPC codes are already assigned, so 424 genuinely has no preimage. The same constraint blocks 412 for §5.6 conditional writes. Tracked as a single platform ask in wix-private/universal-scheduling-protocol-spec#261.

[maoryeh]

Rebased onto current master — was DIRTY, now MERGEABLE.

The branch had diverged from master at the root (183 commits of unrelated history), so a rebase was the wrong tool; the change is replayed as a single cherry-pick onto 1b025c4 instead. Content is unchanged: 3 files, +25/-2. Only CHANGE_LOG.md conflicted, and only on ordering — the entry is placed in date order between the 14/09 and 11/09 ones, keeping its original 13/09 date since that is when the change was written.

tools/usp_check.py all gives identical results before and after: schemas, refs, vectors, coherence all ok; authority reports the same 56 pre-existing failures on clean master as with this change, since that check wants a built site.

Context for reviewers: this closes one of the four symptoms on wix-private/universal-scheduling-protocol-spec#261. usp-impl already returns 401 for this case — PrivilegedOperationGate.java:156-161 does it deliberately — so today the implementation is non-conformant against a §9.4 MUST purely because the table has not been narrowed. Merging makes the shipped behaviour correct rather than requiring a code change.