feat(config): make config schema and fix workflow language-agnostic

Problem

The fix workflow hardcodes setup-node and setup-python steps keyed off node_version and python_version in .blender/blender.yml. This works for Node and Python repos but doesn't extend to Go, Rust, Java, Ruby, etc.

The config schema reinforces this: node_version and python_version are top-level fields, which signals that BLEnder is tied to those two ecosystems.

Proposed change

Replace language-specific fields with a generic mechanism. Two options:

Option A: runtimes list

repo_name: "My Project"
install_command: "npm ci"
runtimes:
  - name: node
    version: "22"
  - name: python
    version: "3.11"
  - name: go
    version: "1.22"

The fix workflow would loop over entries and call the matching actions/setup-* action.

Option B: setup_commands list

repo_name: "My Project"
setup_commands:
  - "apt-get install -y golang-1.22"
install_command: "go mod download"

More flexible. No need to map runtime names to actions. But loses caching benefits of actions/setup-*.

Files to change

• config/defaults.yml — update schema
• .github/workflows/fix-dependabot-pr.yml — replace hardcoded setup steps with a loop or matrix
• scripts/setup-prompt.md — update Step 3 to generate the new format
• README.md — update config reference

Migration

Keep node_version and python_version working during a transition period. The workflow can check for both old and new fields.

Start by reading config/defaults.yml, .github/workflows/fix-dependabot-pr.yml, scripts/setup-prompt.md, and the README config reference. Compare the proposed runtimes and setup_commands approaches, then trace how the existing node_version and python_version fields are consumed. Done means the chosen generic schema is documented and generated, the workflow supports it while preserving both legacy fields during migration, and the affected setup instructions are updated.