fix(core): MessagingVars membership tests use in — prototype names (constructor, toString, __proto__) are falsely rejected as built-in variables #747

Problem

Messaging variable handling in packages/core/src/messaging/vars.ts tests membership in the built-in variable tables with the in operator, which also matches inherited Object.prototype members. Variable names that are perfectly legal under the module's own name grammar (/^[A-Za-z_][A-Za-z0-9_]*$/) — constructor, toString, hasOwnProperty, valueOf, isPrototypeOf, __proto__ — are therefore treated as if they were built-in computed/time/constant variables:

• MessagingVars.set rejects them with {constructor} is computed and cannot be overridden (or "is built in"), so a custom variable with one of these names can never be stored, even though no built-in variable by that name exists.
• The variable list silently drops a configured variable with one of these names from the configured-vars section.
• The time-variable and session-field gates take the same false-positive branch (they happen to return undefined afterwards, so resolution is not corrupted — but the gates are wrong and the next edit that trusts them will be).

The rest of the codebase already uses Object.hasOwn for exactly this hazard (e.g. packages/core/src/rpc.ts, packages/core/src/workspace/driver.ts), and the same collision class was fixed for provider IDs in #673 and alias lookups in #414. These five sites in vars.ts were missed.

Evidence (verified this run, 2026-10-28)

• packages/core/src/messaging/vars.ts:203 — if (!(key in MessagingTemplate.sessionFields)) return undefined
• packages/core/src/messaging/vars.ts:211 — if (name in MessagingTemplate.timeVars) return timeValue(name, now)
• packages/core/src/messaging/vars.ts:373 — .filter((name) => !(name in MessagingTemplate.constants)) (variable list)
• packages/core/src/messaging/vars.ts:418 — if (input.name in MessagingTemplate.contextVars || input.name in MessagingTemplate.timeVars) → rejects with "is computed and cannot be overridden"
• packages/core/src/messaging/vars.ts:424 — if (input.name in MessagingTemplate.constants) → rejects with "is built in"
• The tables are plain object literals: packages/core/src/messaging/template.ts:29 (constants), :204 (sessionFields), :218 (contextVars, built by spreading Object.fromEntries(...) into a literal), :251 (timeVars) — none is prototype-free, so in sees Object.prototype.
• Laptop probe (probe dir ~/git/fleet/probe-2026-10-28-vars-proto/ on the laptop; imports the real MessagingTemplate from the laptop clone at b0633cc697, whose vars.ts/template.ts sha256 are byte-identical to sandbox main): for each of constructor, toString, hasOwnProperty, valueOf, __proto__, isPrototypeOf — in constants === true, in timeVars === true, in contextVars === true, while Object.hasOwn(constants, name) === false and constant(name) === undefined. Controls behave correctly: separator is an own constant (constant() === "/"), system_time/unix are own time vars, session_id is an own context var. The NAME regex at vars.ts:110 accepts all six prototype names.
• Existing tests pin the true-positive rejections that must keep working: packages/core/test/messaging.test.ts:196 (session_id rejected as computed) and :200 (separator rejected as built-in).

Why it matters

setVar is exposed to sessions and the user (via packages/core/src/plugin/host.ts:433). A legal variable name is refused with a misleading reason ("computed"/"built in" when it is neither), and there is no workaround — the name is simply unusable as a messaging variable, and a configured variable with that name vanishes from the variable list while still resolving. It is the same silent prototype-collision class the fleet has already fixed twice (#673, #414); leaving a third instance invites the next one to corrupt data instead of merely refusing a name.

Acceptance criteria

• All five membership tests in packages/core/src/messaging/vars.ts (lines 203, 211, 373, 418, 424) use own-property checks (Object.hasOwn or equivalent), matching the house pattern in rpc.ts / workspace/driver.ts.
• setVar accepts and stores custom variables named constructor, toString, hasOwnProperty, valueOf, isPrototypeOf, and __proto__, and such a variable resolves normally in template rendering; storing __proto__ must not mutate any object's prototype (the value lives in the DB / a Map, and the fix must keep it that way).
• True positives still reject: session_id (context) and system_time (time) as computed, separator (constant) as built-in — the existing tests at messaging.test.ts:196,200 keep passing.
• A configured variable named e.g. toString appears in the variable list output instead of being filtered out.
• New tests in the messaging test set pin at least constructor and __proto__ as settable/resolvable custom variables, plus the list-visibility case.
• No change to resolution order (args → facts → custom → configured constants) or to any real built-in variable's behaviour.