feat(loader): interpolate the entry disabled field

The Windows platform layer disables tool-bash and inserts the pwsh stack, but the shipped presets each mount a tool-bash row that re-enabled the tool on win32 — the session had both a PowerShell-backed bash tool and tool-pwsh, silently, because no spec pinned the composed preset layer.

The Loader now evaluates a disabled: !!js expression against the loader context at every mount decision; disabled is the only interpolated metadata field, and the raw node stays in the options so write-back keeps the !!js form. The standard/code/cordis presets gate tool-bash with process.platform === 'win32', verify-cordis-config allows expressions in disabled only, and the windows-shell spec pins the preset-level invariant.

scripts/verify-cordis-config.spec.ts

@@ -0,0 +1,23 @@
+/**
+ * The verify-cordis-config metadata contract: `disabled` is the one entry
+ * metadata field whose `!!js` expression the Loader interpolates; every other
+ * metadata field must stay static, and a disabled expression must parse.
+ */
+
+import { describe, expect, it } from 'vitest'
+import { metadataExpressionErrors } from './verify-cordis-config.ts'
+
+describe('verify-cordis-config metadata expressions', () => {
+  it('accepts a disabled !!js expression', () => {
+    const problems = metadataExpressionErrors(
+      { id: 'tool-bash', name: '@deepseek-ai/dsh-tool-bash', disabled: { __jsExpr: "process.platform === 'win32'" } },
+      '[0]',
+    )
+    expect(problems).toEqual([])
+  })
+
+  it('rejects an expression in a static metadata field', () => {
+    const problems = metadataExpressionErrors({ id: { __jsExpr: 'process.platform' }, name: 'pkg' }, '[0]')
+    expect(problems).toContain('[0].id: !!js is not interpolated here')
+  })
+})