Document structured capacity errors

docs/roadmap/notarius-promptkit-wishlist.md

@@ -205,8 +205,8 @@ resolution.
 
 ## Priority 4: Structured Capacity Errors
 
-**Disposition:** Accepted into the
-[structured capacity errors](capacity-errors.md) feature roadmap.
+**Disposition:** Implemented behavior. See the consumer guide's
+[Handle Errors](../consumers/pkg-promptkit.md#handle-errors) section.
 
 ### Downstream need
 
@@ -215,46 +215,16 @@ provider-neutral application error. When multiple backends are active,
 operators would benefit from knowing which backend rejected admission without
 parsing an error string or exposing endpoint details.
 
-### Current integration
+### Implemented behavior
 
-PromptKit provides the useful `ErrCapacityExceeded` sentinel. Notarius can
-classify the failure reliably, but it retains only a sanitized diagnostic
-string as additional context.
-
-### Requested capability
-
-Add a typed error that continues to match `ErrCapacityExceeded`:
-
-```go
-type CapacityError struct {
-	BackendID string
-}
-
-func (e *CapacityError) Is(target error) bool {
-	return target == ErrCapacityExceeded
-}
-```
-
-The exact implementation may use `Unwrap` or another idiomatic mechanism. The
-important properties are compatibility with `errors.Is` and discoverability
-through `errors.As`.
-
-### Design considerations
-
-- Include the stable backend ID.
-- Do not expose the backend endpoint, credential environment, credential
-  value, request content, or other sensitive configuration.
-- Consider including the configured concurrency and queue limits if they are
-  useful and safe, but backend identity alone provides most of the downstream
-  value.
-- Add a retry delay only if PromptKit can provide a meaningful value. A full
-  queue does not necessarily imply a reliable `Retry-After` duration.
-- Keep retry and backoff policy with the consuming application. PromptKit
-  should classify the admission failure rather than silently retry it.
+PromptKit now retains the broad capacity classification while allowing
+Notarius to obtain the selected backend ID without parsing diagnostic text.
+The consumer guide owns the application workflow, including retry and backoff
+policy.
 
 ### Value to Notarius
 
-This would improve operational diagnostics and future metrics while preserving
+This improves operational diagnostics and future metrics while preserving
 the provider-neutral error boundary used by Notarius.
 
 ## Capabilities PromptKit Already Provides Well
@@ -311,7 +281,8 @@ Notarius would be:
 1. Add atomic execution that returns prepared details and the completed result.
 2. Add a semantic execution-target digest, preferably alongside profile
    inspection.
-3. Add a typed capacity error carrying backend identity.
+3. Use the implemented typed capacity error where backend admission diagnostics
+   are needed.
 
 The first addresses a concrete execution workaround. The second would improve
 checkpoint correctness and reduce coupling. The third is operational polish.