fix(doctor): resolve the SQLite database through the framework's own keys

[geodro]

A Symfony project was reported as having an empty database needing migrations, and clicking the fix ran migrations against a project with no migration classes at all, so Doctrine answered that there were none registered. The database it complained about was a 0-byte file the application never opens; the one the site actually uses was healthy the whole time.

The check read DB_CONNECTION and DB_DATABASE wherever it found them, which are Laravel's key names:

if !strings.EqualFold(envfile.ReadKey(envPath, "DB_CONNECTION"), "sqlite") { return }
dbFile := envfile.ReadKey(envPath, "DB_DATABASE")

A Symfony project keeps its SQLite path inside the DATABASE_URL DSN and declares neither key, so where those keys survived as leftovers from something else they were read as though they meant something.

It reads only keys the project's own framework declares now, taking the whole vocabulary from the definition's service detection rules and vars. A framework declaring the flat pair is read through it exactly as before. A DSN is read as a DSN, so a project genuinely on SQLite through a connection string is found rather than passed over, with Symfony's project-root placeholder resolved away. A framework declaring nothing, or a project with no framework at all, falls back to the convention a bare project follows, since there is no vocabulary to respect.

Reading by declared key also means the format no longer matters, so the check moved out of the dotenv-only gate: a framework configured through a PHP settings file is checked through its own dotted keys, and its database file is found in the same block that names its driver. The app-key and drift checks stay behind that gate, one of them diffing against a committed dotenv example.

checkServerDatabase has the same shape and still reads DB_HOST and DB_DATABASE by name. It is left for its own change.

Refs #1392