Correct profile source validation and identity

docs/internal/sources.md

@@ -40,13 +40,22 @@ duplicate detection, and source containment:
 ## Profiles And Built-Ins
 
 `internal/profile` loads and validates execution profiles from an
-operating-system filesystem or an `fs.FS`. Its overlay repository consults the
-next repository only when the higher-precedence repository reports that a
-profile is absent. Strict YAML decoding recognizes the optional `backend`
-field, trims its value, and requires a model plus at least one non-blank
-backend or endpoint. Loading does not check registry membership because the
-available registry belongs to the assembled engine; the runner checks
-membership during preparation and exact profile inspection.
+operating-system filesystem or an `fs.FS`. A file contains exactly one YAML
+document and its trimmed YAML `id` is its only selection identity; filenames do
+not confer authority. Strict selected decoding recognizes the optional
+`backend` field, trims its value, and requires a model plus at least one
+non-blank backend or endpoint. File-backed `extra_params` values are validated
+and defensively copied through the shared bounded JSON-value owner before a
+profile is published. OpenAI-compatible reserved-field policy remains with the
+model-client and backend-registry owners.
+
+The overlay repository consults the next repository only when the
+higher-precedence repository reports that a profile is absent. A reliably
+selected malformed profile stops fallback, while an unrelated malformed file
+does not become authoritative through its filename. Loading does not check
+backend registry membership because the available registry belongs to the
+assembled engine; the runner checks membership during preparation and exact
+profile inspection.
 
 The root engine assembles profile repositories in precedence order: in-memory
 profiles, one ordinary configured source, an application fallback source, then