feat: add dev-dependency-in-production rule

[CallumHoward]

What

Adds a new dev-dependency-in-production rule: a package in devDependencies that is imported by production (non-test, non-config) source code via a runtime/value import is flagged so it can be promoted to dependencies. It is the promote-side mirror of the existing test-only-dependency and type-only-dependency rules.

Detection (crates/core/src/analyze/unused_deps.rs::find_dev_dependencies_in_production) reuses the existing prod-vs-test file partition and the per-import value/type accounting the sibling detectors already rely on:

• flags only when a production file has a runtime/value import of the dev dep;
• does not flag type-only production imports (erased at build time — mirrors type-only-dependency);
• does not flag imports that come only from test/config files (that's test-only-dependency's job);
• skips workspace packages, known tooling (@types/*, typescript, …), ignoreDependencies entries, and packages also declared in dependencies / peerDependencies / optionalDependencies.

Default severity warn; rule key dev-dependencies-in-production; suppress a package via ignoreDependencies. Wired through the full analyzer contract per the analyzer-authoring guide: IssueKind + issue_meta rows, RulesConfig, the DevDependencyInProduction struct + Finding wrapper + move-to-prod action, human / JSON / SARIF / Code Climate / compact / markdown output, fallow explain, the LSP diagnostic, regression baselines, the GitHub Action + GitLab CI jq summaries, the VS Code extension, and all generated contracts (schema.json, output schema, npm registry/capabilities, TS types, SKILL.md).

Why

Closes #1738.

Fallow catches dependency demotion drift but not promotion drift. A devDependency value-imported from production code passes silently today — unlisted-dependency doesn't fire because the package is listed, just under the wrong section — yet pnpm install --prod omits it and the import breaks at runtime.

Repro before this change:

// package.json
{ "devDependencies": { "yaml": "^2.0.0" } }

// src/index.ts (reachable production code)
import { parse } from "yaml";
export const load = (s: string): unknown => parse(s);

$ fallow dead-code --fail-on-issues
✓ No issues found            # exit 0  ← the gap

After: the same project reports dev-dependency-in-production for yaml and exits 1 under --fail-on-issues, while a type-only import or a test-only import stays silent.

Test plan

• cargo test --workspace, cargo clippy --workspace --all-targets -- -D warnings, cargo fmt --all -- --check — green.
• New integration test (tests/fixtures/dev-dep-in-prod + crates/core/tests/integration_test/dev_dep_in_prod.rs) proving the value-import flag and the type-only / test-only / prod-dependency abstains end to end via fallow_core::analyze.
• New unit tests (crates/core/src/analyze/unused_deps_tests/dev_dep_in_prod.rs) covering the flag plus each abstain path (type-only, test-only, ignored, workspace, known-tooling, peer-dependency).
• npm run generate:contracts:check, action/tests/run.sh (415 passed), ci/tests/run.sh (317 passed), and the VS Code vitest suite (615 passed) all pass.
• Updated JSON/SARIF snapshots and the config/output schema drift gates.

Note: this rule checks the root package.json against the project-wide import graph, matching the existing test-only/type-only detectors; true per-workspace attribution is a shared follow-up across all three dependency-family rules.

---

Just a first pass, I didn't see anything against AI-aided contributions in CONTRIBUTING.md – happy to close this or for more knowledgeable contributors to update if a more expert human contribution is desired.