[kvlonge]

Why

CHI-561: when sqb rename gives a model a name from another layer (for example int_clean to int_enriched), the file stays in its folder and verification fails the layer-folder rules (SQBRPROJECT102/105). The output only listed the rule failures, so it looked as if SQLBuild could not rename and move in one step, although sqb mv with a .sql destination already does.

Changes

• When a model rename fails verification only on SQBRPROJECT102/105 for the renamed file, the output says where the model belongs and prints the exact one-step sqb mv <old> <path>.sql. The path swaps the folder of the model's current layer for the new layer's folder and keeps the folders around it. --project-dir is repeated when given, quoting follows the platform's shell, and the note says to change the folder if wanted.
• Without the current layer's folder in the path, or a folder for the new layer, the destination is models/<folder>/<new_name>.sql.
• Any other failure, including a layer failure mixed with another rule, keeps its current text. No automatic move: sqb rename still never moves files. No layer setting is involved, so no TOML hint.
• Docs: the rename/mv reference gains a "Rename or move" section with three examples (name only; name and folder; folder only), and Refusals describes the hint and links to it. The bundled skill copy is regenerated.

Verification

• New E2E through the real CLI on a DuckDB project with the layer rules: the cross-layer rename is refused with the prefilled command and nothing is written; running the printed command succeeds and the project matches a rename plus a manual move. Also a placeholder case and two other refusals that print no hint.
• Unit cases for the suggested path, placeholder and mixed failures.
• Focused refactor E2E/unit and skills tests, make check-ci, public-repository scan.