Feature Request: Interactive (Optional) Staging of Unstaged Files Before pre-commit Execution

### Description: **Problem:** Currently, `pre-commit` is designed to run its hooks exclusively on *staged* files. When a user attempts to commit with unstaged changes in their working directory, `pre-commit` temporarily stashes these unstaged changes, runs its hooks on the staged files, and then unstashes the changes. This behavior, while intentional to ensure hooks only operate on what's being committed, can lead to a less intuitive and sometimes frustrating workflow for users, especially when: 1. A user intends to commit all relevant changes but has forgotten to `git add` some files. 2. Hooks (e.g., auto-formatters like `ruff-format`) modify files, resulting in new unstaged changes that then require manual `git add .` and a re-attempt of the commit. 3. The user might be unaware of existing unstaged changes that could be relevant to the commit or might cause issues if not included. This workflow often requires manual intervention (e.g., `git status`, `git add .`, re-running `git commit`) if unstaged files are present and intended to be part of the commit, or if hooks introduce new unstaged changes that need to be staged. **Proposed Solution:** Introduce an optional, configurable interactive mechanism within `pre-commit` (or as a dedicated "meta-hook" in `pre-commit-hooks`) that, when enabled, performs the following steps *before* `pre-commit` runs its main checks: 1. **Detect Unstaged Files:** Check if there are any unstaged files in the working directory. 2. **Notify and List:** If unstaged files are found, inform the user about their presence and list them (similar to the "Changes not staged for commit" section of `git status`). 3. **Prompt for Staging:** Ask the user if they would like to automatically stage these unstaged files (e.g., "Unstaged files detected. Would you like to `git add .` them before running hooks? [Y/n]"). 4. **Execute `git add .` (if confirmed):** If the user confirms (e.g., by typing 'Y' or pressing Enter for a default 'Y'), execute `git add .` to stage all currently unstaged changes. 5. **Proceed with `pre-commit`:** After staging (or if the user declines the prompt), `pre-commit` proceeds with its normal hook execution on the now (potentially) updated set of staged files. **Benefits:** * **Improved User Experience:** Streamlines the commit workflow by reducing manual steps and context switching when unstaged files are present. * **Reduced Friction:** Helps users ensure all intended changes are included in the commit and processed by hooks without needing to abort and restart the commit process. * **Enhanced Awareness:** Makes users immediately aware of any forgotten unstaged files that might be relevant to their commit. * **Consistency:** Promotes a more consistent state for `pre-commit` checks by ensuring all relevant changes are staged before hooks run. **Considerations/Alternatives:** * Some GUI tools (e.g., GitHub Desktop) manage staging differently, often presenting all modified and new files as implicitly 'staged' by default within their UI, effectively including them in the commit and thus subjecting them to `pre-commit` hooks without an explicit `git add .` command from the user. * It's important to note that this proposed interactive feature is primarily aimed at improving the workflow for users interacting with `pre-commit` via the command-line interface (CLI). GUI-based Git clients handle staging and committing through their own interfaces, and `pre-commit` hooks do not typically inject interactive prompts into these graphical workflows. * This feature should be **opt-in**, configurable via `.pre-commit-config.yaml`, to avoid changing existing workflows for users who prefer manual control or have specific staging strategies. * The prompt should be clear, concise, and provide an easy default (e.g., 'Y') for quick acceptance. * While custom shell scripts in `.git/hooks/pre-commit` or external tools like `lint-staged` can achieve similar outcomes, integrating this functionality directly into `pre-commit` or `pre-commit-hooks` would provide a standardized, more portable, and easier-to-manage solution for the wider user base. * This proposal focuses on handling unstaged files *before* `pre-commit` hooks run. A separate, but related, enhancement could be to prompt for staging *after* hooks modify files, but that might introduce additional complexity in interaction and scope. For this initial request, focusing on the state *before* hooks run is a more straightforward and impactful improvement.