fix(init): skip interactive prompts when --resume is passed (closes #2098)

[Larslllllll]

Summary

When repowise init --resume is run on a TTY, the entire interactive questionnaire runs again (banner, mode menu, provider selection, etc.), defeating the purpose of --resume.

The git-tier is already handled correctly by effective_run_mode_for_resume() (computed before the interactive gate, so a fast resume never re-prompts for it). All other prompts were not similarly gated.

Root cause

is_interactive at line 1010 had no check for resume:

is_interactive = sys.stdin.isatty() and provider_name is None and not index_only and not yes

Fix

1. Added and not resume to the is_interactive expression, so resume runs always fall through to the non-interactive path.
2. Added a one-line console notice (e.g. [dim]Resuming a full run — reusing stored configuration.[/dim]) so the user can see the run was picked up rather than restarted.

The non-interactive path reads stored configuration from .repowise/config.yaml and state.json, so the prior run's provider, model, language, and other choices are reused automatically.

Fixes #2098

[RaghavChamadiya]

Thanks @Larslllllll, and sorry for the collision: #2106 was opened against #2098 two days before this and is already through review, so that is the one I am going to land. Nothing wrong with your read of the bug, you landed on the same one-line gate.

Two differences worth knowing for next time, since neither is obvious from the issue. #2106 lifts the predicate out into a small _interactive_gate function with a case per flag, so the questionnaire cannot be re-opened by a later flag without a test going red; the inline and chain here has no such guard. And its notice avoids saying anything about how to suppress itself, which is the one thing I held that PR on: the print is unconditional under if resume:, so a line offering a way to silence it would be false in both versions.

If you want another one in the same area, #2137 is open and unassigned: editor_files: {vscode_mcp: false} is a key repowise writes and then never reads back, and the thread has the two gates that cause it. Say the word on that issue and it is yours.

I am leaving this open rather than closing it today: if #2106 goes quiet on the string change I asked for, yours is the fallback and I will merge it instead. Either way you will hear which on this thread.