fix(config): promote project_name to core (closes #2279) (#2348)

* fix(config): promote project_name to core, fixes #2279

project_name was a bmm-specific prompt despite being a universal
project-level concept used by every module — including core skills like
bmad-brainstorming, which loads from _bmad/core/config.yaml and was
silently broken because project_name lived under bmm. Users without bmm
installed could not run brainstorming at all.

Move:
- src/core-skills/module.yaml: declare project_name with prompt
  "What is your project called?" and default {directory_name}, matching
  what bmm previously had.
- src/bmm-skills/module.yaml: remove the bmm definition; add project_name
  to the "Variables from Core Config inserted" header comment so
  contributors can see what's inherited.

Migration for existing installs:
- tools/installer/modules/official-modules.js: after loadExistingConfig
  reads each per-module config.yaml, hoist any keys that are now declared
  in core but appear under non-core modules. Without this, the partition
  logic in writeCentralConfig (which strips core keys from non-core
  buckets) would silently drop the user's prior project_name on the next
  quick-update. Generic — handles project_name today and any future
  module→core promotions.
- The hoist preserves precedence: an existing core value beats a stale
  module-side copy.

--yes seed:
- tools/installer/ui.js: add project_name to the hardcoded core seed
  (using path.basename(directory) to match the {directory_name} default)
  so non-interactive fresh installs populate it. Without this the seed
  silently omits project_name and core skills fall back to literals.

Tests:
- test/test-installation-components.js Suite 43 (9 assertions) covers
  the schema move, the loadExistingConfig hoist, and the precedence rule.
- Suite 35 fixture updated: project_name moved from bmm bucket to core,
  with a stale bmm copy left in place to verify it gets stripped.

Verified manually:
- Fresh install -y: project_name lands in [core] of config.toml.
- Existing install with project_name in bmm/config.yaml: quick-update
  hoists it to [core] and strips it from [modules.bmm].

* fix(installer): harden config-load against malformed config.yaml

Per augment review on #2348: loadExistingConfig stored any truthy
yaml.parse result (including scalars like '42'), which would later crash
_hoistCoreKeysFromLegacyModuleConfigs at \`key in cfg\` with
"Cannot use 'in' operator to search for ... in 42".

- loadExistingConfig: only keep parses that are plain objects (not
  scalars or arrays). A corrupt config.yaml is now treated the same as
  a parse error — skipped, not crashed-on.
- _hoistCoreKeysFromLegacyModuleConfigs: belt-and-suspenders type guards
  on _existingConfig.core (in case it's populated by some other path)
  and on each module cfg in the loop.
- Test Suite 43 adds 2 assertions covering a scalar core/config.yaml:
  loadExistingConfig must not crash, and bmm.project_name must still
  hoist into a clean core bucket.