AssertionError instead of a clean config error when pyproject.toml sets a non-table `rules` value

Bug

sqlfluff crashes with a raw, uncaught AssertionError (instead of a clean config-loading error) when a pyproject.toml sets rules directly under [tool.sqlfluff] to something that isn't a table.

Repro

$ cat pyproject.toml
[tool.sqlfluff]
dialect = "ansi"
rules = "all"

$ echo "select 1" > test.sql
$ sqlfluff lint test.sql
Traceback (most recent call last):
  ...
  File ".../sqlfluff/core/config/toml.py", line 119, in load_toml_file_config
    assert isinstance(rules_section, dict), (
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Expected to find section in `rules` section of config, but instead found all

This reproduces on current main (818243e2f) with any command that loads config (lint, fix, parse, even version).

Why this happens

load_toml_file_config (src/sqlfluff/core/config/toml.py) narrows the rules section with a bare assert isinstance(rules_section, dict). That assert was added incidentally during a 2024 strict-typing pass (#6206), not as a deliberate design decision.

.sqlfluff ini files support a top-level scalar rules = all under [sqlfluff] (see default_config.cfg), so it's an easy mistake to write the toml equivalent as [tool.sqlfluff] + rules = "..." instead of the actually required [tool.sqlfluff.rules.<rule_name>] per-rule tables. When that happens, the assert trips.

get_config() in the CLI (src/sqlfluff/cli/commands.py) only catches SQLFluffUserError around config loading, so the AssertionError is never caught and the user gets a full Python traceback instead of the clean "Error loading config: ..." message every other malformed-config case (e.g. an invalid layout section) produces.

Expected

A SQLFluffUserError with a message pointing at the correct [tool.sqlfluff.rules.<rule_name>] syntax, matching how other config sections are validated.

I have a small fix + regression test ready and will open a PR shortly.