[v2 Bug] Fusion drops explicit config.group → top-level group on unattached test nodes (source-attached generic + singular tests)

### 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
On the Fusion (v2) engine, a test node whose `attached_node` is `null` — i.e. **every generic test defined on a source**, and **every singular test** — does not carry an explicit `config.group` on its top-level `group` property; `group` stays `null`. dbt Core (1.x) copies `config.group` into `group` for these same nodes.

Controlled comparison: one project, `dbt parse` through each engine, identical files/profile/command — the only variable is the engine binary.

| test node | parent | `attached_node` | `config.group` | `group` (Core 1.12.1) | `group` (Fusion 2.0.0-preview.205/.208) |
|---|---|---|---|---|---|
| generic `not_null` on a **model** (model in a group) | model | model | — | `test_group` | `test_group` |
| generic `unique` on a **model** (explicit config) | model | model | `test_group` | `test_group` | `test_group` |
| generic `not_null` on a **group-less model** (explicit config) | model | model | `test_group` | `null` | `null` |
| generic `not_null` on a **source** (explicit config) | source | null | `test_group` | **`test_group`** | **`null`** ← bug |
| **singular** test on a source (in-SQL config) | source | null | `test_group` | **`test_group`** | **`null`** ← bug |
| **singular** test on a model (in-SQL config) | model | null | `test_group` | **`test_group`** | **`null`** ← bug |

Generic tests attached to a **model** behave identically on both engines (group comes from the parent model via inheritance; the test's own `config.group` is ignored there — note the group-less-model row is `null` on **both**). The divergence is exactly the `attached_node = null` nodes.

### Expected Behavior
For `attached_node = null` test nodes, Fusion should populate the top-level `group` from the node's explicit `config.group`, matching dbt Core.

### Steps To Reproduce
Warehouse-agnostic; `dbt parse` is sufficient (no warehouse connection needed).

`models/groups.yml`
```yaml
version: 2
groups:
- name: test_group
owner: {name: Repro Owner, email: repro@example.com}
```
`models/staging/sources.yml`
```yaml
version: 2
sources:
- name: raw_src
schema: public
tables:
- name: raw_table
columns:
- name: id
data_tests:
- not_null: {config: {group: test_group}} # generic test on a SOURCE, explicit group
```
`models/staging/schema.yml`
```yaml
version: 2
models:
- name: stg_thing
config: {group: test_group}
columns:
- name: id
data_tests:
- not_null # inherited
- unique: {config: {group: test_group}} # explicit config on a model test
```
`models/staging/stg_thing.sql` → `select 1 as id`

`tests/singular_on_source.sql`
```sql
{{ config(group='test_group') }}
select * from {{ source('raw_src','raw_table') }} where false
```
`tests/singular_on_model.sql`
```sql
{{ config(group='test_group') }}
select * from {{ ref('stg_thing') }} where false
```

1. Run `dbt parse` with Fusion, and separately with dbt Core 1.12.1.
2. In each `target/manifest.json`, compare `config.group` vs `group` for every test node:
```bash
python3 - <<'PY'
import json
for n in json.load(open('target/manifest.json'))['nodes'].values():
if n.get('resource_type') == 'test':
print(n['name'], '| config.group=', (n.get('config') or {}).get('group'), '| group=', n.get('group'))
PY
```
3. Fusion prints `group=None` for the source and singular tests; dbt Core prints `group=test_group`.

Reproduces on Fusion `2.0.0-preview.205`, latest `2.0.0-preview.208`, and earliest `2.0.0-preview.1` (i.e. the whole 2.0 line — not a regression between Fusion builds).

### Relevant log output
```shell
# same source test node, both engines (only `group` differs):
# CORE 1.12.1 -> config.group='test_group' group='test_group'
# FUSION .205/.208 -> config.group='test_group' group=None
```

### Environment
```markdown
- OS: macOS
- CPU: ARM
- dbt distribution and version: dbt-fusion 2.0.0-preview.205 (also .208 latest, .1 earliest); reference dbt Core 1.12.1 (dbt-snowflake 1.12.0)
```

### Which database adapter are you using?
snowflake (behavior is adapter-independent; repro is parse-only)

### Is this a discrepancy vs. dbt 1.x?
- [x] Yes — this works in dbt 1.x but not in dbt v2.x

### Additional Context
Model/group notifications route on a node's top-level `group` (not `config.group`), so source-attached and singular tests placed in a group never produce group-level notifications on Fusion — silently, with no error. Reported by a customer.

Related: dbt-core#12107 (singular-test group inheritance), dbt-core#9339 (group/access for sources). Sibling engine:v2 manifest-parity bugs (already fixed): dbt-core#14493 (test `kwargs`), #13883 (`node.path`), #14179 (state:modified false positives), #13535 (`child_map`/`parent_map`).