docs(skills): readonly is stripped from any non-system write, not only an update (#15382)

The published catalog told application authors that a non-system write has a
readonly field stripped from an UPDATE payload. As of the 2026-09-03 ruling the
engine applies the same strip on the create path, so the sentence understated
the rule on exactly the write where an author is most likely to seed a
protected column.

Both files say 'any non-system write' now, and the automation skill names
create_record beside update_record and the step warning that reports the drop.
Paid inside the token ratchet by deleting 'silently' -- which the same ruling
made false: the drop is reported through droppedFields and a step warning.


Claude-Session: https://claude.ai/code/session_01ARYe3yQTQCUFm5qPYNgKaJ

Co-authored-by: Claude <noreply@anthropic.com>

Author: claude[bot]

skills/objectstack-automation/SKILL.md

@@ -233,8 +233,9 @@ run reports success. `objectstack validate` names the offending template.
 
 > **Writing a `readonly` field? Set `runAs: 'system'`.** `readonly: true`
 > governs the end-user surface: under the default `runAs: 'user'`, the engine
-> **silently strips** a `readonly` field from an `update_record` payload
-> — the step reports success but the value never lands. A flow that
+> **strips** a `readonly` field from any non-system write — `create_record` and
+> `update_record` alike — the step reports success but the value never lands,
+> and the drop is named in the step's warnings. A flow that
 > maintains a `readonly` field (approval stamps, conversion flags, SLA
 > markers, rollups) must run `runAs: 'system'`, the trusted-writer channel.
 > `os validate` / `os build` fail a `runAs:'user'` `update_record` that writes

skills/objectstack-data/SKILL.md

@@ -271,7 +271,7 @@ export const Invoice = ObjectSchema.create({
   incoming changes when the predicate is `TRUE`.
 - **`readonly: true` governs the end-user surface, not trusted system writers.**
   A non-system write (REST/UI, and any `runAs:'user'` flow — the default) has
-  the field **silently stripped** from an UPDATE payload; the write reports
+  the field **stripped** from any non-system write; the write reports
   success but the value never lands. System-context writes —
   `runAs:'system'` flows, system hooks, seeds, imports, migrations — are exempt
   and DO write it. So the pattern "users can't edit this, but automation