Fix incorrect timing parameter passed to run_scanners

[codewithfourtix]

Fix timing=timeout typo in run_scanners call in run_scan

The run_scanners call was passing timeout (a float, default 120.0) as the timing argument instead of the timing boolean flag. This caused per-file scan timings to always be collected regardless of the --timing CLI option.

Tasks

• Reviewed [contribution guidelines](https://github.com/nexB/scancode-toolkit/blob/develop/CONTRIBUTING.rst)
• PR is descriptively titled 📑 and links the original issue above 🔗
• Tests pass -- look for a green checkbox ✔️ a few minutes after opening your PR
  Run [tests](https://scancode-toolkit.readthedocs.io/en/latest/contribute/contrib_dev.html#running-tests) locally to check for errors.
• Commits are in uniquely-named feature branch and has no merge conflicts 📁
• Updated documentation pages (if applicable)
• Updated CHANGELOG.rst (if applicable)

[Copilot]

Pull request overview

Fixes an incorrect argument being passed to run_scanners() from the main scan orchestration path (run_scan()), so that per-file scan timing collection correctly follows the --timing CLI flag rather than being implicitly enabled by the (truthy) timeout value.

Changes:

• Correct run_scanners(..., timing=...) to use the timing boolean instead of timeout.
• Restores expected CLI behavior where per-file scan timings are only collected when --timing is enabled.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Consider adding a regression test that fails if --timing is not provided but per-file scan timings are still collected (e.g., assert scan_codebase(..., with_timing=...) receives False, or that outputs/resources do not include scan_timings unless --timing is set). This bug was caused by accidentally passing timeout into the timing parameter, and without a negative test it could regress silently again.

[codewithfourtix]

Will address in a follow-up PR