dbt_lineage waits 120 s for a dbt adapter that doesn't start when writes are allowed #1666

Found during the v0.12.9 release review (#1647).

In a dbt project with writes allowed (builder sessions, tool run --allow-write), dbt_lineage starts the dbt adapter. dbt deps finishes, then the start doesn't complete, and after adapterStartTimeoutMs (120 s) the call answers from the manifest with "the dbt adapter didn't start within 120 s". Read-only calls are not affected.

Observed on the built 0.12.9 binary on the jaffle-shop sample, with the machine under heavy load, so load may be part of it:

• Two builder sessions on serve took 143 s and 135 s per turn; a later call stalled again.
• tool run dbt_lineage --allow-write reported status: ok but exited 1 with Subprocess.send() cannot be used after the process has exited (ERR_IPC_CHANNEL_CLOSED, python-bridge). serve logged the same error and stayed up.
• The bundled dbt integration (0.2.14) has no getModelLineage, so a successful start would still answer from the manifest.
• v0.12.8's dbt_lineage didn't use the adapter.

To do: retest on an idle machine, skip the adapter when the integration can't answer (or take #1368), and handle the late bridge error so a successful call exits 0. The CHANGELOG entry for structured dbt_lineage should also say that the bundled integration doesn't provide it yet.