Surface missing shared ESLint config prerequisites during planning

[jabelic]

Goal

Prevent diff and apply --dry-run from presenting a shared ESLint entrypoint as ready-to-adopt when the target repository is missing the required shared config package.

Background

• During the pilot validation in Pilot the base quality preset on i18n-at and document adoption gaps #2, the planned eslint.config.mjs for Jabelic-Works/i18n-at imported @jabelic/eslint-config/base.
• i18n-at does not currently depend on @jabelic/eslint-config.
• The template already notes that standards apply does not yet teach target repositories to add those dependencies.
• Without a first-class warning, prerequisite, or blocked state, a pilot can look safe even though it still requires hidden manual follow-up before the generated config would work.

Scope

• Detect when a planned shared ESLint entrypoint depends on a package that is not present in the target repository, or surface that prerequisite clearly in planning output.
• Decide how that state should appear in human-readable and JSON output.
• Document the current manual follow-up expectation while dependency mutation remains out of scope.

Out of Scope

• Automatically installing dependencies into target repositories.
• Designing the full dependency-management workflow for every shared config package.
• Reworking all stack-specific ESLint integration behavior.

Acceptance Criteria

• When the target repository lacks @jabelic/eslint-config, planning output clearly communicates that prerequisite.
• Reviewers can tell whether the generated eslint.config.mjs is actually ready to adopt or still blocked on manual setup.
• README and/or command help explains the current behavior and the expected follow-up.

PR Plan

• 1 issue = 1 PR.
• Keep the change focused on prerequisite detection/reporting and the minimal docs or tests needed to make that behavior clear.

Proposed Plan

1. Inspect how planned changes are currently represented in the planner output.
2. Add a prerequisite or warning path for shared ESLint config generation when the target package is missing.
3. Cover the behavior in tests for both human-readable and JSON output as needed.
4. Update docs to explain the current limitation and the expected manual follow-up.
5. Re-run the pilot validation from Pilot the base quality preset on i18n-at and document adoption gaps #2 to confirm the output is explicit.

Notes

• Tracked by Pilot the base quality preset on i18n-at and document adoption gaps #2.
• This issue is about making pilot planning honest and reviewable before any apply step.