lang 2.4: lock protocol-pack access semantics (interface-only)

Design decision: a protocol-constrained pack element is viewed THROUGH the
constraint protocol — only the protocol's interface (its methods, and the
projections xs.T / xs.value) is accessible, not arbitrary concrete members,
exactly like a constrained generic `T: Show`. So `xs[i].v` (a field on the
concrete IntBox, not declared on Show) is an error; the constraint is enforced
and bounds the body regardless of the concrete arg types at a call site.

The previous example 191 demonstrated `xs[i].v` — which only compiled because
the constraint is not yet enforced. Trimmed it to the protocol-agnostic part
that's correct today (per-shape binding + comptime `xs.len` across arities /
heterogeneous shapes); protocol-interface access + projection are the remaining
2.4 work. specs.md records the access rule.

specs.md

@@ -990,6 +990,16 @@ A pack is **not a runtime value** — it lowers to N typed positional parameters
 below; using the pack name where a runtime value is required is an error (see
 "Pack as value").
 
+**Element access is through the protocol, not the concrete type.** Although the
+pack monomorphizes per call shape and each element has a known concrete type,
+`xs[i]` is viewed **through the constraint protocol**: only the protocol's own
+interface (its methods, and the projections `xs.T` / `xs.value`) is accessible.
+Reaching a concrete member that isn't part of the protocol — e.g. `xs[i].v`
+where `v` is a field of the concrete `IntBox` but not declared on `Show` — is an
+error, exactly as it would be for a constrained generic `T: Show`. The protocol
+constraint is enforced (each trailing arg must conform) and bounds what the body
+may do, regardless of the concrete arg types at any particular call site.
+
 #### Pack operations
 
 | Use | Spelling | Meaning |