feat(miner-plan): wire the feasibility gate into a new MCP tool + miner CLI command

[JSONbored]

The feasibility-gate composer itself is done: buildFeasibilityVerdict (packages/gittensory-engine/src/feasibility.ts:50) is a pure, fully-implemented go/raise/avoid verdict over claim status, duplicate-cluster risk, and issue quality/lifecycle status, exported from the package's public entrypoint (packages/gittensory-engine/src/index.ts:219-228). Nothing calls it yet — this issue is only the wiring around it.

Confirmed by grep: there is no feasibility MCP tool registration anywhere in src/mcp/server.ts or packages/gittensory-mcp/bin/gittensory-mcp.js (no server.registerTool("gittensory_..._feasibility_..."), nor an equivalent tool-name/shape declaration, in either file).

There are two plausible homes for the MCP tool, with a real trade-off between them:

• packages/gittensory-mcp/bin/gittensory-mcp.js (the local stdio MCP wrapper, @jsonbored/gittensory-mcp) already depends on @jsonbored/gittensory-engine (>=0.1.0 <1.0.0, packages/gittensory-mcp/package.json:41) and already imports subpaths from it elsewhere in the same package (packages/gittensory-mcp/lib/local-branch.js:5), even though bin/gittensory-mcp.js itself doesn't import the engine yet. Its closest sibling tools are gittensory_validate_linked_issue (packages/gittensory-mcp/bin/gittensory-mcp.js:385-397) and gittensory_check_before_start (same file, lines 399-415) — feasibility.ts's own header comment says the composer "composes the same go/raise/avoid decision as the pre-start check's core recommendation logic." But those two sibling tools both proxy to the hosted API (apiPost against /v1/repos/{owner}/{repo}/check-before-start, etc.) — a feasibility tool would be meaningfully different in shape: a pure, synchronous, LOCAL computation with no API round-trip, which is exactly what feasibility.ts's header means by "without pulling in repo records or GitHub caches."
• src/mcp/server.ts is the hosted, in-process MCP server (70+ server.registerTool(...) calls, e.g. gittensory_get_contributor_profile at lines 1304-1305) where tools call internal functions directly with no round-trip. But the root package.json does not depend on @jsonbored/gittensory-engine at all today (confirmed — no such entry) — wiring the tool here means adding that cross-package dependency first, a bigger-footprint change than extending a package that already declares it.

Given the composer's explicit local/pure design and that packages/gittensory-mcp already declares the dependency, that package is the more natural fit — but this issue should make the call explicitly (and document it in the PR) rather than leave it implicit.

The CLI half is more mechanical. packages/gittensory-miner/bin/gittensory-miner.js dispatches every subcommand with a flat sequence of if (cliArgs[0] === "<command>") { process.exit(run<X>Cli(...)); } blocks (see queue/ledger/plan/governor at lines 41-55), each delegating to a run<X>Cli export from a sibling lib/<name>-cli.js file, and packages/gittensory-miner/lib/cli.js's printHelp (lines 5-37) lists every command's usage string in one place. A new feasibility command should mirror this exactly. Because the composer only takes already-known discriminants (claimStatus, duplicateClusterRisk, issueStatus) and does no fetching of its own, the CLI command needs a way to supply them — at minimum as flags, and possibly sourcing claimStatus from the local claim ledger (packages/gittensory-miner/lib/claim-ledger.js, see the sibling claim-ledger CLI issue) once that lands. That data-sourcing design is left to the implementer.

Deliverables

• Register a new MCP tool (e.g. gittensory_feasibility_gate) wired to buildFeasibilityVerdict — in packages/gittensory-mcp/bin/gittensory-mcp.js (preferred, see reasoning above) or src/mcp/server.ts; document which was chosen and why in the PR
• New packages/gittensory-miner/lib/feasibility-cli.js exporting a runFeasibilityCli(args, options)-style entrypoint that calls buildFeasibilityVerdict, following the parse → execute → render(json|table) → exit-code convention used by runQueueCli (packages/gittensory-miner/lib/portfolio-queue-cli.js:209-215)
• New gittensory-miner feasibility ... dispatch branch added to packages/gittensory-miner/bin/gittensory-miner.js, mirroring the queue/ledger/plan blocks at lines 41-51
• printHelp in packages/gittensory-miner/lib/cli.js updated with the new command's usage line(s)
• Tests for both the MCP tool wiring and the CLI command's argument parsing + output rendering

References

• packages/gittensory-engine/src/feasibility.ts:50 (buildFeasibilityVerdict, the composer)
• packages/gittensory-engine/src/index.ts:219-228 (public export)
• packages/gittensory-mcp/bin/gittensory-mcp.js:385-397 (gittensory_validate_linked_issue, sibling tool pattern)
• packages/gittensory-mcp/bin/gittensory-mcp.js:399-415 (gittensory_check_before_start, the sibling tool feasibility.ts's own header says it mirrors)
• packages/gittensory-mcp/package.json:41 (existing @jsonbored/gittensory-engine dependency)
• packages/gittensory-mcp/lib/local-branch.js:5 (existing subpath-import precedent from the engine package within this file's own package)
• src/mcp/server.ts:1304-1305 (gittensory_get_contributor_profile, the alternate hosted-tool pattern)
• packages/gittensory-miner/bin/gittensory-miner.js:41-55 (CLI dispatch pattern to mirror)
• packages/gittensory-miner/lib/cli.js:5-37 (printHelp, needs the new usage line)
• packages/gittensory-miner/lib/portfolio-queue-cli.js:209-215 (runQueueCli, closest existing CLI-subcommand dispatch pattern)
• Wave 2 tracker 🧩 Wave 2 — Analyze, Plan, Create & Deploy (HELD tracker) #2353, Phase 2

[linear-code]

JSO-3257