Split core application and CLI modules behind compatibility facades #112

Summary

Split the two largest production modules into responsibility-focused modules while preserving their current import paths.

Measured at develop commit 902c759:

• nitrostack/core/app.py: 2,273 lines
• nitrostack/cli/main.py: 2,000 lines

See docs/investigations/file-length-limit.md for the investigation and proposed boundaries.

Scope

• Separate schema/input normalization, request context, registration and definitions, tool invocation and results, resources and prompts, task protocol handling, and startup from core/app.py where ownership is clear.
• Move CLI project template constants out of cli/main.py; organize command handlers for init/run, generation and project operations, and client registration.
• Keep each resulting hand-maintained Python module at or below 500 physical lines. If embedded data makes that impractical, extract it to a non-Python asset or document a specific exception.
• Preserve nitrostack.core.app.McpApplication, McpApplicationFactory, existing documented imports, the nitrostack.cli.main:main console entry point, and python -m nitrostack.cli.main.
• Keep internal imports one-directional; implementation modules must not import back through compatibility facades.

Acceptance criteria

• Existing public imports and CLI entry points continue to work.
• Generated CLI project output remains behaviorally compatible and focused tests cover the preserved imports and output.
• New implementation modules are at or below 500 physical lines, except for an explicitly justified data-heavy asset boundary.
• The split introduces no import cycles or unrelated behavior changes.

Wait for PR #37 to merge before editing core/app.py, and PR #16 before editing cli/main.py. Rebase on current develop and remeasure after those PRs land.

Out of scope: unrelated refactors, behavior changes, and broad cleanup.