Document BigQuery job continuation and partial-parsing behavior

### Contributions

- [x] I have read the [contribution guide](https://github.com/dbt-labs/docs.getdbt.com/blob/current/CONTRIBUTING.md).

### Link to page

- https://docs.getdbt.com/reference/resource-configs/bigquery-configs
- https://docs.getdbt.com/reference/parsing

### Describe the problem

dbt-adapters issue https://github.com/dbt-labs/dbt-adapters/issues/2070 proposes an opt-in `job_continuation_key` for dbt-bigquery. A later dbt invocation can use the same key to attach to matching BigQuery query/copy jobs and continue dbt's materialization control flow.

The parsing reference also says every environment-variable change in `profiles.yml` causes a full parse. Since dbt-core #9844, Python dbt hashes only credential values exposed through `connection_info()` / `{{ target }}`. Runtime-only credential fields deliberately omitted from `_connection_keys()` do not change that hash.

### Describe the improvement

- Document the `job_continuation_key` BigQuery profile option, its opt-in semantics, and an environment-variable example.
- State that the raw key is not included in BigQuery job IDs or logs.
- State that the field is runtime-only and unavailable through `{{ target }}` or `dbt debug`.
- Clarify the Python dbt partial-parsing documentation so it distinguishes target-visible profile values from runtime-only credential values.
- Note that Fusion support is separate until it implements an equivalent runtime-only transport.

Start with the linked BigQuery configurations and parsing reference pages, then review the dbt-adapters issue and dbt-core #9844 for the stated behavior. Update both documentation areas to cover the opt-in job_continuation_key, its environment-variable example and runtime-only limitations, and distinguish target-visible values from runtime-only credentials, including the separate Fusion support note.

Written by the indexing model from the issue text.