Clarify bundled profile composition and compatibility

docs/roadmap/bundled-openrouter.md

@@ -184,13 +184,29 @@ application supplying only a new model value does not inherit the replaced
 profile's backend. A distinct sibling using `extends` remains the ordinary way
 to create a variant while retaining base fields.
 
+These replacement semantics describe ordinary identified-list upsert behavior.
+Honor explicit ConfigKit sequence modes as well: `append` rejects duplicate
+identities, while `replace` replaces the complete lower list. The bundle adds no
+special conflict handling or exception to those composition rules.
+
 Loading definitions by default changes inventory and inspection results, and
 previously unresolved references matching bundled IDs may become resolvable.
-Document these effects. Existing valid application records at higher layers
-continue to win through normal composition. Changing a bundled backend may
+Document these effects. Higher-layer application records take precedence under
+the applicable ConfigKit composition mode. Changing a bundled backend may
 also affect surviving bundled profiles that reference it; that is ordinary
 backend completion, not a special override exception.
 
+The five cost-tier profiles inherit from the effective `auto` profile. An
+application replacement of `auto` can therefore change their inherited backend
+or model while their OpenRouter plugin settings remain present. Cover this
+interaction in a focused test and a short example note; it does not require a
+new restriction on replacing the parent.
+
+Bundled profile and backend IDs are consumer-facing names. Review future removal
+or repurposing through the ordinary compatibility process, since application
+configuration may reference them. This does not introduce a separate catalog
+lifecycle or a guarantee that upstream aliases retain fixed behavior.
+
 The embedded data ships with the PromptKit release. No catalog download or
 automatic refresh mechanism is planned. Provider aliases and routers may change
 their targets independently of that release; the inspected configured slug
@@ -199,7 +215,9 @@ does not identify or pin the concrete model selected upstream.
 ## Implementation Work
 
 1. Verify the provider endpoint and exact model values for the seventeen selected
-   root profiles.
+   root profiles. Local HTTP checks establish payload construction, not provider
+   acceptance. A live provider check may supplement that verification without
+   becoming a recurring credential-dependent test requirement.
 2. Add the embedded YAML backend and profiles, and integrate their dedicated
    underlay with engine construction. Add the disable option using the existing
    facade option pattern. Apply the ordinary load/normalize/validate lifecycle.
@@ -208,7 +226,10 @@ does not identify or pin the concrete model selected upstream.
    Include an application-provided OpenRouter collection and a replaced backend
    to exercise interaction with external catalogs. Verify all five cost-tier
    profiles inherit the base backend/model and send the expected top-level
-   `plugins` array through the built-in HTTP client.
+   `plugins` array through the built-in HTTP client. Add representative explicit
+   `append` and `replace` mode cases. Add a targeted case replacing root `auto`
+   in a higher layer with a different backend/model, then verify its cost-tier
+   children inherit those effective values and retain their plugin settings.
 4. Verify listing and inspection reflect effective definitions and meaningful
    source evidence. Exercise request preparation with a fake client or local
    server as appropriate; construction must not depend on provider reachability