[v2 Bug] Profile Jinja rendering coerces connection strings into YAML mappings

### Is this a new bug in dbt-core v2?

Yes. This reproduces with the v2 parser used by dbt-core 1.12.0 and in the current Rust `dbt-profile` implementation on `main`.

### Current behavior

A quoted profile value that mixes literal text with Jinja is rendered and then parsed again as YAML. If the rendered string contains YAML-significant text such as `: `, the value changes type.

For example, a DuckDB attachment connection string:

```yaml
my_project:
target: dev
outputs:
dev:
type: duckdb
path: ":memory:"
attach:
- path: "ducklake:postgres: host={{ env_var('DB_HOST') }} port=5432"
alias: lake
```

fails during v2 profile parsing with:

```text
attach[0].path: invalid type: map, expected a string
```

The same profile is accepted by the Python dbt profile renderer and dbt-duckdb.

A related type-coercion problem also affects exact `env_var` expressions: an environment variable containing `5432` is implicitly converted to a YAML number even without an `as_number` filter.

### Expected behavior

- Mixed Jinja templates should remain strings after rendering.
- Exact Jinja expressions should preserve the value returned by the expression.
- Explicit native filters such as `as_number` should continue to return typed values.

This matches the established rendering split already used by the Rust `dbt-jinja-utils` renderer.

### Root cause

`dbt-profile::render_value_recursive` calls `env.render_str` and then unconditionally attempts `dbt_yaml::from_str` for any Jinja-containing string. Re-parsing the rendered output as a standalone YAML document causes connection strings containing `: ` to become mappings and numeric-looking environment variables to become numbers.

### Additional context

This is adjacent to, but not fixed by, #14451. That issue added support for DuckDB `extensions` configured as maps; it did not change the profile renderer's post-Jinja YAML coercion behavior.

A regression test and focused fix are being prepared against `main`.