A behavior has rows of its own, so loading no longer drops Run in editor

`deserializeProject` builds each asset's effective schema in pass 1 and coerces
`props` against it in pass 2. For a behavior that schema was
`[...COMMON_PROPS, ...variables]` -- but `runInEditor` lives in
`ASSET_SCHEMAS.behavior`, not in `COMMON_PROPS`, so `normalizeBag` dropped the
value as undeclared. The flag therefore survived no save: every reload switched
it back off.

The fix is the full schema, `schemaFor('behavior')`, which is what
`schemaForAsset` hands out everywhere else.

Found by a round-trip test comparing the whole project rather than one field. An
existing test had the loss written down as its expectation
(`{ enabled, speed }`), which is why nothing ever reported it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/core/store/serialize.ts

@@ -40,7 +40,6 @@ import {
 import { type FlatItem, makeFlatItem } from '../properties/listItems';
 import {
   coerceValue,
-  COMMON_PROPS,
   isValidFieldName,
   isValidVariableName,
   type PropertyDef,
@@ -76,7 +75,9 @@ export function deserializeProject(raw: unknown, fallbackId = ''): Project {
     if (a.type === 'behavior') {
       const vars = normalizeVariables(a.variables);
       variables.set(a.id, vars);
-      schemas.set(a.id, [...COMMON_PROPS, ...vars]);
+      // The full schema, not just the common rows: this is what pass 2 coerces `props` against, and
+      // a behavior's own `runInEditor` would be dropped as undeclared.
+      schemas.set(a.id, [...schemaFor('behavior'), ...vars]);
     } else if (a.type === 'particles') {
       // A source's rows end with its own graph's parameters, so the graph is needed before the
       // overrides of the objects placed from it can be coerced.