ix config set silently no-ops on nested boolean keys (e.g. domain.enableExternal)

[kreneskyp]

Summary

ix config set local domain.enableExternal false reports success but does not persist the change to ~/.config/ix/config.d/local.yaml. Subsequent ix config get returns the old value, and loadConfig() continues to read the unchanged on-disk value.

Repro

Starting state in ~/.config/ix/config.d/local.yaml:

domain:
  hosts:
    - dev.ix
    - terra.ix
  enableExternal: true
  external: null
  publicBaseUrl: null

$ ix config set local domain.enableExternal false
 • local.domain.enableExternal → false
 ✧  Set local.domain.enableExternal in /home/peter/.config/ix/config.d/local.yaml.

$ ix config get local domain.enableExternal
 • local.domain.enableExternal  — true

$ grep enableExternal ~/.config/ix/config.d/local.yaml
  enableExternal: true

Confirmed with a second invocation (quoted 'false') — same result. Only one file exists under config.d/, so no layering is masking the write.

Workaround: hand-edit the YAML.

Expected

ix config set should either:

• Persist the boolean and have ix config get reflect it, or
• Fail loudly if the value type is rejected by the schema (it should not silently report success).

Impact

Blocks normal operation when enableExternal is true with external: null (FR-037-CON-3 throws at loadConfig()), since the documented escape hatch — turning off enableExternal via ix config set — does nothing.

Likely scope

• Boolean parsing / coercion path in ix config set for nested dotted keys
• Worth checking other primitive types (numbers, null) on nested keys too

Refs: FR-018 (ix config commands), FR-037 (domain config), packages/local/src/config.ts:287-301 (FR-037-CON-3 enforcement).