[v2 Bug] get_column_lineage returns empty array despite confirmed lineage

### Is this a new bug in dbt v2.x compared to the latest version of dbt 1.x?

- [x] I believe this is a new bug in dbt v2.x
- [x] I have searched the existing issues and could not find a duplicate

### Current Behavior

The `get_column_lineage` tool (exposed via the remote dbt MCP server's LSP integration) returns an empty array `[]` with `isError: false` for every model tested, regardless of whether upstream lineage exists.

Seems the LSP is also not responding to column-level requests in the dbt Cloud UI — after working with engineering, this seems to point to a Fusion LSP issue rather than an MCP transport issue.

### Expected Behavior

`get_column_lineage` should return column lineage nodes tracing how a column's value is derived from upstream sources, consistent with what get_lineage (model-level) already confirms exists.

### Steps To Reproduce

Set up a Fusion-enabled dev environment with a multi-hop model chain (in my repro: `settlement_credit_eod` → `stg_foo` → `foo`)

Confirm model-level lineage works:
```
curl -s -X POST "https:///api/ai/v1/mcp/" \
-H "Authorization: Token " \
-H "x-dbt-prod-environment-id: " \
-H "x-dbt-dev-environment-id: " \
-H "x-dbt-user-id: " \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","method":"tools/call","id":1,"params":{"name":"get_lineage","arguments":{"unique_id":"model.repro_122896.foo","depth":2}}}'
```
Result: Returns `foo` with `parent stg_foo`, `stg_foo` with parent `settlement_credit_eod`. Full 3-hop lineage exists.

Call `get_column_lineage` on the same model:
```
curl -s -X POST "https:///api/ai/v1/mcp/" \
-H "Authorization: Token " \
-H "x-dbt-prod-environment-id: " \
-H "x-dbt-dev-environment-id: " \
-H "x-dbt-user-id: " \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","method":"tools/call","id":2,"params":{"name":"get_column_lineage","arguments":{"model_id":"model.repro_122896.foo","column_name":"session_id"}}}'
```
Result: `[], isError: false`

### Relevant log output

```shell
get_lineage (working — confirms lineage exists):
Returns foo with parent stg_foo, stg_foo with parent settlement_credit_eod. Full 3-hop lineage exists.

get_column_lineage (broken — returns empty):
[], isError: false

No error, no stack trace — just an empty array on a model with confirmed upstream lineage.
```

### Environment

```markdown
Fusion-enabled environment
Auth method: Personal Access Token (PAT)
MCP
Multi-tenant deployment
```

### Which database adapter are you using?

_No response_

### Is this a discrepancy vs. dbt 1.x?

- [ ] Yes — this works in dbt 1.x but not in dbt v2.x

### Additional Context

- Engineering saw that the model foo.sql is querying for `+column:model.repro_122896.foo.AMOUNT+` but the result is [] from the LSP. We initially thought that the column name is case sensitive so we've tested with both uppercase and lowercase column names — same empty result.

- `get_lineage` (model-level) works correctly on the same environment, confirming the lineage graph is intact — only `get_column_lineage` returns empty.

- After working with engineering, seems the LSP is also not responding to column-level requests even in the dbt Cloud UI — this points to a Fusion LSP issue rather than an MCP transport issue.

- Authentication (PAT) succeeds with HTTP 200. The tool is registered and callable — it simply returns empty data.