[FEATURE] Ship a focused archunitpy check CLI over the existing rule API

[TristanKruse]

Context

This is the check-only, first deliverable of #39. The existing public API already supports running rules without pytest via Checkable.check() (and assert_passes()); what is missing is a packaged command that users can invoke directly in CI, pre-commit, or a terminal. #39 also proposes graph, report, and init, which can remain separate follow-up work.

Goal

Ship a small first-party archunitpy check console command over the existing rule engine. Keep pytest fully supported, and let projects define each rule once and use that definition from either entry point. The CLI should not introduce a second analyzer, a second rule language, or implicit discovery of arbitrary tests.

Proposed first slice

• Register archunitpy as a packaged console script. Implement check first; leave other subcommands out of this change.
• Require an explicit rules source. Support a documented Python module:attribute (or equivalently explicit) interface for named Checkable rules so the full fluent API remains available. Supporting the existing JSON rules_from_config() as a second input is useful, but JSON must not be the only path: it currently covers only three rule types.
• Run each selected rule through its existing .check() path; reuse existing violation/evidence formatting and check options where applicable. Preserve rule names and deterministic ordering in multi-rule output.
• Define and document stable outcomes (proposed: exit 0 for success, 1 for architecture violations, 2 for invocation/configuration/import errors). Diagnostics for invalid rule sources and exceptions in user rule definitions should identify the source and not be reported as architecture violations.
• Resolve project/config paths predictably and document the working-directory/module-import behavior. Never silently run zero rules.

Acceptance criteria

• A wheel-installed archunitpy check works without invoking pytest and without adding a runtime dependency.
• The README shows one Python rule definition reused by pytest and the CLI, plus a CI invocation. If JSON input is included, document its current rule-type limits.
• Success, one or more violations, malformed/missing rules, import errors, and an empty rules source have tested, documented exit behavior. Violation output retains the same underlying evidence as the library API.
• Multiple named rules run once each with stable output; a clean rule does not hide a failing one.
• Tests cover absolute/relative paths and invocation from a different working directory, as well as an installed-console-script smoke test on supported Python versions.
• Regression tests compare CLI results with direct .check() / pytest for representative forbidden-dependency and cycle cases, including a seeded failure. Existing library and pytest tests remain green.
• Before making any performance claim, run paired, repeatable benchmarks of the packaged CLI against the direct API and pytest on clean and seeded-failure workloads; report startup and checking time separately. Do not set a flaky wall-clock threshold in CI.

Non-goals for this issue

Automatic rule/test discovery, replacing pytest, expanding the JSON DSL, implementing graph/report/init, or changing dependency extraction and resolution. Those can be handled independently after the minimal command has a clear contract.