docs: update guides for perfectionist import_granularity rule

Mirror the markdown guide updates from the previous `perfectionist`
upgrade. The upgrade in #433 added the
`perfectionist::import_granularity` rule, which now enforces merged
imports automatically. Document this in CONTRIBUTING.md and drop the
now-redundant manual bullet from the AI instruction templates.

https://claude.ai/code/session_01CMrfXtuzxpSbchSJNuwboK

Author: claude

.github/copilot-instructions.md

@@ -7,7 +7,6 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c
 - Commit format: Conventional Commits. Pattern: `type(scope): lowercase description`. The scope is optional.
 - Version releases are the only exception. The commit message is just the version number, such as `0.21.1`.
 - Write documentation, comments, and other prose for ease of understanding first. Prefer a formal tone when it does not hurt clarity, and use complete sentences. Avoid mid-sentence breaks introduced by em dashes or long parenthetical clauses. Em dashes are a reliable symptom of loose phrasing; when one appears, restructure the surrounding sentence so each clause stands on its own rather than swapping the em dash for another punctuation mark.
-- Prefer merged imports.
 - Use descriptive names for generics, such as `Size` and `Report`. Do not use single letters.
 - Use descriptive names for variables and closure parameters. Single letters are permitted only in these cases: (1) conventional names like `n` for count or `f` for formatter; (2) comparison closures like `|a, b|`; (3) trivial single-expression closures; (4) fold accumulators; (5) index variables `i`/`j`/`k` in short closures or index-based loops; and (6) test fixtures with identical roles. Single letters are never permitted in multi-line functions or closures.
 - Use `pipe-trait` to chain through unary functions such as constructors, `Some`, `Ok`, and free functions. Use it to flatten nested calls and to continue method chains. Do not use it for simple standalone calls; prefer `foo(value)` over `value.pipe(foo)`.

AGENTS.md

@@ -7,7 +7,6 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c
 - Commit format: Conventional Commits. Pattern: `type(scope): lowercase description`. The scope is optional.
 - Version releases are the only exception. The commit message is just the version number, such as `0.21.1`.
 - Write documentation, comments, and other prose for ease of understanding first. Prefer a formal tone when it does not hurt clarity, and use complete sentences. Avoid mid-sentence breaks introduced by em dashes or long parenthetical clauses. Em dashes are a reliable symptom of loose phrasing; when one appears, restructure the surrounding sentence so each clause stands on its own rather than swapping the em dash for another punctuation mark.
-- Prefer merged imports.
 - Use descriptive names for generics, such as `Size` and `Report`. Do not use single letters.
 - Use descriptive names for variables and closure parameters. Single letters are permitted only in these cases: (1) conventional names like `n` for count or `f` for formatter; (2) comparison closures like `|a, b|`; (3) trivial single-expression closures; (4) fold accumulators; (5) index variables `i`/`j`/`k` in short closures or index-based loops; and (6) test fixtures with identical roles. Single letters are never permitted in multi-line functions or closures.
 - Use `pipe-trait` to chain through unary functions such as constructors, `Some`, `Ok`, and free functions. Use it to flatten nested calls and to continue method chains. Do not use it for simple standalone calls; prefer `foo(value)` over `value.pipe(foo)`.

CLAUDE.md

@@ -7,7 +7,6 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c
 - Commit format: Conventional Commits. Pattern: `type(scope): lowercase description`. The scope is optional.
 - Version releases are the only exception. The commit message is just the version number, such as `0.21.1`.
 - Write documentation, comments, and other prose for ease of understanding first. Prefer a formal tone when it does not hurt clarity, and use complete sentences. Avoid mid-sentence breaks introduced by em dashes or long parenthetical clauses. Em dashes are a reliable symptom of loose phrasing; when one appears, restructure the surrounding sentence so each clause stands on its own rather than swapping the em dash for another punctuation mark.
-- Prefer merged imports.
 - Use descriptive names for generics, such as `Size` and `Report`. Do not use single letters.
 - Use descriptive names for variables and closure parameters. Single letters are permitted only in these cases: (1) conventional names like `n` for count or `f` for formatter; (2) comparison closures like `|a, b|`; (3) trivial single-expression closures; (4) fold accumulators; (5) index variables `i`/`j`/`k` in short closures or index-based loops; and (6) test fixtures with identical roles. Single letters are never permitted in multi-line functions or closures.
 - Use `pipe-trait` to chain through unary functions such as constructors, `Some`, `Ok`, and free functions. Use it to flatten nested calls and to continue method chains. Do not use it for simple standalone calls; prefer `foo(value)` over `value.pipe(foo)`.

CONTRIBUTING.md

@@ -36,7 +36,7 @@ Automated tools enforce formatting (`cargo fmt`), linting (`cargo clippy`), and
 
 ### Import Organization
 
-Prefer **merged imports**. Combine multiple items from the same crate or module into a single `use` statement with braces rather than separate `use` lines. Import ordering is enforced by `cargo fmt`. Imports gated by a platform attribute such as `#[cfg(unix)]` go in a separate block after the main imports.
+**Merged imports** are enforced by the `perfectionist::import_granularity` rule. With the `crate` granularity configured in `dylint.toml`, multiple items from the same crate are combined into a single `use` statement with braces rather than separate `use` lines. The intended long-term granularity is `module`, but it is set to `crate` for now (see issue [#432](https://github.com/KSXGitHub/parallel-disk-usage/issues/432)). Import ordering is enforced by `cargo fmt`. Imports gated by a platform attribute such as `#[cfg(unix)]` go in a separate block after the main imports.
 
 ```rust
 use crate::{

template/ai-instructions/shared.md

@@ -7,7 +7,6 @@ Read and follow the CONTRIBUTING.md file in this repository for all code style c
 - Commit format: Conventional Commits. Pattern: `type(scope): lowercase description`. The scope is optional.
 - Version releases are the only exception. The commit message is just the version number, such as `0.21.1`.
 - Write documentation, comments, and other prose for ease of understanding first. Prefer a formal tone when it does not hurt clarity, and use complete sentences. Avoid mid-sentence breaks introduced by em dashes or long parenthetical clauses. Em dashes are a reliable symptom of loose phrasing; when one appears, restructure the surrounding sentence so each clause stands on its own rather than swapping the em dash for another punctuation mark.
-- Prefer merged imports.
 - Use descriptive names for generics, such as `Size` and `Report`. Do not use single letters.
 - Use descriptive names for variables and closure parameters. Single letters are permitted only in these cases: (1) conventional names like `n` for count or `f` for formatter; (2) comparison closures like `|a, b|`; (3) trivial single-expression closures; (4) fold accumulators; (5) index variables `i`/`j`/`k` in short closures or index-based loops; and (6) test fixtures with identical roles. Single letters are never permitted in multi-line functions or closures.
 - Use `pipe-trait` to chain through unary functions such as constructors, `Some`, `Ok`, and free functions. Use it to flatten nested calls and to continue method chains. Do not use it for simple standalone calls; prefer `foo(value)` over `value.pipe(foo)`.