rename_schema_field rekeys Core/System-protected fields with no protection check (same guard bypass) #2195

Summary

rename_schema_field validates only that the source field exists and the destination doesn't, never its protection level, so update_schema's rename_fields can rekey a Core/System-protected field and migrate all node data to the new key, corrupting a core type.

Failure scenario

handle_update_schema's Phase-0 namespace check (schema/mod.rs:716-721) only rejects renaming TO a bare name on a core type; renaming a Core field to a prefixed name is allowed. Calling update_schema with {"schema_id":"task","rename_fields":[{"from":"status","to":"custom:status"}]} passes that check, then rename_schema_field (schema.rs:544) performs no SchemaProtectionLevel check and migrates every task node's status property data to custom:status, rewriting the stored schema. The hardcoded TaskNodeBehavior and the frontend read properties.task.status, which is now missing, breaking status rendering/validation across all existing tasks. Same root cause as the remove_fields gap: the schema-mutation path never consults protection levels and never calls can_modify_field. A fix that only guards removal leaves this rename path independently exploitable.

Location

packages/core/src/services/node_service/schema.rs:557

Severity

important

Found via a full-repo adversarial bug sweep, independently verified by two separate skeptical reviewers reading the actual current code before filing.