feat(miner-scale): add fleet run-manifest for multi-repo worktree scheduling

[JSONbored]

There is currently no "run manifest" concept anywhere in the repo (confirmed by search) — this is a new, top-level fleet-operator config, and it is NOT the same thing as .gittensory-miner.yml (packages/gittensory-miner/docs/miner-goal-spec.md), which is worth stating explicitly since the naming is easy to conflate. .gittensory-miner.yml lives in and is authored by a target repo's maintainer — it tells a miner how that one repo wants to be approached (wantedPaths, maxConcurrentClaims, etc.). The run-manifest this issue adds is authored by the miner operator running fleet mode (sibling Phase 6 Dockerfile issue) — it says which repos to work across at all, and how to split a finite worktree/concurrency budget between them. Same naming convention, opposite author and opposite direction of intent — the miner-goal-spec doc's own comparison table (miner-goal-spec.md:14-21) is a good template for stating this distinction clearly in the new doc.

This is the scheduling input the concurrency allocator (sibling Phase 6 issue) and the existing cross-repo portfolio queue need to actually run a fleet: packages/gittensory-miner/lib/portfolio-queue.js already stores a prioritized, cross-repo backlog (miner_portfolio_queue table, repo_full_name + identifier + priority), and packages/gittensory-miner/lib/opportunity-fanout.js already fans out GitHub search/listing across multiple {owner, repo} targets — but nothing today declares which repos are in scope for a fleet run or how many concurrent worktrees each one gets. The run-manifest is that declaration.

Deliverables

• A run-manifest schema (YAML or JSON, following the existing .gittensory-miner.yml precedent of "every field optional, unknown keys ignored, malformed field falls back to a documented default with a warning" — docs/miner-goal-spec.md:12) listing target repos and a per-repo (and/or total) concurrency budget.
• A pure parser (mirroring parseMinerGoalSpecContent's safe-default-fallback shape, not a hard-fail on a malformed file) living in @jsonbored/gittensory-engine alongside the existing parseMinerGoalSpec/parseMinerGoalSpecContent.
• Document the distinction from .gittensory-miner.yml explicitly (author, direction, scope) in whatever doc this issue adds under packages/gittensory-miner/docs/.
• Wire the parsed manifest as an input the fleet allocator (sibling issue) and portfolio-queue.js's cross-repo backlog can both read from — this issue only needs to produce the parsed, typed manifest; actually driving the allocator from it can be the allocator issue's job if that's cleaner, but say which side owns the wiring.
• Unit tests under test/unit/ following test/unit/miner-goal-spec-parser.test.ts's pattern for the sibling parser.

References

• packages/gittensory-miner/docs/miner-goal-spec.md:14-21 — the .gittensory.yml vs .gittensory-miner.yml comparison table to model the new manifest-vs-goal-spec distinction on.
• packages/gittensory-miner/lib/portfolio-queue.js:12,89-98 — the existing cross-repo miner_portfolio_queue table this manifest's scheduling would feed.
• packages/gittensory-miner/lib/opportunity-fanout.js:18-31 (normalizeTargets) — the existing multi-repo target normalization the manifest's repo list should be compatible with.
• Sibling Phase 6 issue: feat(miner-concurrency): add git-worktree-per-attempt allocator — the consumer of this manifest's concurrency budget.
• test/unit/miner-goal-spec-parser.test.ts — test pattern precedent for the sibling MinerGoalSpec parser.

[linear-code]

JSO-3286