add builder config to test node config

[colin-rogers-dbt]

Resolves #10484

Problem

Solution

Checklist

• I have read the contributing guide and understand what's expected of me.
• I have run this code in development, and it appears to resolve the stated issue.
• This PR includes tests, or tests are not required or relevant for this PR.
• This PR has no interface changes (e.g., macros, CLI, logs, JSON artifacts, config files, adapter interface, etc.) or this PR has already received feedback and approval from Product or DX.
• This PR includes type annotations for new and modified functions.

[github-actions]

Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.13%. Comparing base (f6cdacc) to head (efecd00).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10767      +/-   ##
==========================================
- Coverage   89.20%   89.13%   -0.08%     
==========================================
  Files         183      183              
  Lines       23419    23425       +6     
==========================================
- Hits        20892    20879      -13     
- Misses       2527     2546      +19     

Flag	Coverage Δ
integration	86.36% <100.00%> (-0.15%)	⬇️
unit	62.11% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
Unit Tests	62.11% <100.00%> (+<0.01%)	⬆️
Integration Tests	86.36% <100.00%> (-0.15%)	⬇️

[colin-rogers-dbt]

Failing dbt-snowflake test against main: https://github.com/dbt-labs/dbt-snowflake/actions/runs/11042144022/job/30673904052#step:8:575

Succesful tests running against this PR branch: https://github.com/dbt-labs/dbt-snowflake/actions/runs/11041928244/job/30673264899#step:8:572

[gshank]

Prior to this "add_config_call" was generally used for SQL nodes to store the extracted config for re-application after applying schema changes. But generic nodes are a fundamentally different thing making it a bit hard to reason about. Since they are constructed only from schema file definitions, there is no "base" sql file to apply later. The config_call_dict on a node is also stored in the internal manifest (for a partial parsing reason that I remember knowing at one point but am not sure really applies anymore...). But generic tests are very leaf-y things that will always be re-generated when anything above them changes, so having it stored on the generic test node probably isn't an issue.

I think this is fine, but please add some comments to the place where the "add_config_call" is done about why (and how it's different than other uses of that call), and add some tests.

[colin-rogers-dbt]

ic nodes are a fundamentally different thing making it a bit hard to reason about. Since they are constructed only from schema file definitions, there is no "base" sql file t

I have added a short code comment but can elaborate further, I have tried to add a test that validates this but all I have achieved is narrowing down the scope of impact: it appears this only ensure the config is available when the pre_model_hook is run. Since dbt-postgres doesn't definine a generic pre_model_hook (like dbt-snowflake) we can't test this behavior here

[gshank]

There are some failing tests, but I'm approving so you don't have to come back again.