bug(stub-architect): lint-clean does not imply parser-clean; stubs land that fail to load in the target runtime

## Summary
The `stub-architect` agent currently runs the project's linter as its primary "compiles cleanly" gate before committing stub scaffolding. For some languages (notably GDScript), the linter is more permissive than the actual language parser — a file can lint-clean but be unloadable at runtime.

## Repro / observed pattern (sanitized)
1. Stub-architect generates a stub region inside an existing file. The existing file uses tab indentation; the agent emits the new region with 4-space indentation.
2. `gdlint scripts/path/to/file.gd` reports `Success: no problems found`. Stub-architect commits, declares success.
3. A subsequent attempt to actually load the file (e.g., for a unit-test run via the language runtime) fails with: `SCRIPT ERROR: Parse Error: Used space character for indentation instead of tab as used before in the file.` The parser, unlike the linter, enforces single-indent-style.
4. The orchestrator has to dispatch a recovery commit just to convert spaces back to tabs in the stub region.

## Why this matters
The lint-only gate is a category error. The contract that the stub-architect implicitly promises is "this file is loadable by the runtime" — but lint clean does not imply that. For Rust, the equivalent would be "lint clean but type-check fails" (cargo check vs cargo clippy).

## Suggested fix
Add a parser-level "this file actually loads" check to the stub-architect's verification step, before any commit:
- **GDScript**: `godot --headless --check-only` (or import-time validation)
- **Rust**: `cargo check` (already present in the skill's Rust idioms but not articulated as a parser-vs-lint distinction)
- **Python**: `python -c "import "` or `python -m py_compile`
- **TypeScript**: `tsc --noEmit`
- **GDScript-specific**: also detect mixed indentation explicitly via `awk '/^ +\t|^\t+ /'`

Alternatively, codify the principle in the skill: "the lint gate is necessary but not sufficient — run a parser/type/load gate before declaring success."

## Related
- #256 (template assumption that the Rust toolchain conventions translate cleanly elsewhere)