fix: qualify stg_* table references with the staging dataset

[C00ldudeNoonan]

Summary

Fixes #143 — fear_greed_composite.py and entropy_complexity.py queried stg_major_indices, stg_sp500_companies_prices, stg_fred_series, and stg_fixed_income unqualified. BigQueryWarehouseResource.execute_query() resolves unqualified names against its own default dataset (economics_raw), but these are dbt staging models living in economics_staging (dbt_project.yml: staging: +schema: economics_staging).

Fix

• bigquery_warehouse.py: new default_dataset_for_schema(schema) helper — mirrors the existing inline environment-suffix logic (prod/staging/dev), generalized so any schema can be resolved consistently. (checks.py already had a private, near-identical _dbt_dataset() for the same purpose — this makes the pattern importable rather than re-inventing it a third time.)
• Both files: qualify every stg_* reference with default_dataset_for_schema("economics_staging").

Verification

Ran both jobs directly against a live BigQuery target before and after:

• Before: 404 Not found: Table ...economics_raw_dev.stg_major_indices
• After: no more table-not-found errors anywhere. entropy_complexity_signals computed and wrote 682 rows successfully — the main asset now completes end-to-end. fear_greed_signals gets through 4 of 5 query components successfully.

Not fixed here — two separate, pre-existing bugs surfaced once the dataset error stopped masking them

Both jobs still fail overall, but on unrelated root causes:

1. entropy_complexity_job: the shared signal data-quality check (signals/checks.py::_check_signal_table) uses DuckDB-only SQL (DESCRIBE {table}, ISNAN(), ISINF()) that BigQuery rejects. This helper is shared by all 5 signal checks (absorption_ratio, turbulence_index, fear_greed, entropy_complexity, network_correlation), so it likely blocks all of them, not just this one.
2. fear_greed_job: a genuine division by zero in the safe-haven-demand component query (fear_greed_composite.py around line 127) — a data issue in the SQL logic itself, not a reference/dataset bug.

Filing these separately to keep this PR scoped to the dataset-resolution fix.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 23d24d42db

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Resolve dbt dataset suffixes from DBT_TARGET

When Dagster builds or observes dbt with DBT_TARGET=staging while ENVIRONMENT is still prod (the production compose file fixes ENVIRONMENT: prod but allows DBT_TARGET to vary), dbt creates models in economics_staging_staging per profiles.yml:2 and generate_schema_name.sql:3-12, but this helper returns economics_staging. The newly qualified stg_* queries will then read the wrong dataset or 404 in that context; derive this suffix from the active dbt target (DBT_TARGET, with ENVIRONMENT only as a fallback) rather than ENVIRONMENT alone.

Useful? React with 👍 / 👎.

[C00ldudeNoonan]

Applied the Codex suggestion (aa85f2e): default_dataset_for_schema() now resolves the suffix from DBT_TARGET first (falling back to ENVIRONMENT), matching what profiles.yml/generate_schema_name.sql actually key off.

Turned out this local deployment's own container has exactly the mismatch Codex described: DBT_TARGET=prod but ENVIRONMENT=LOCAL. Under the old logic this silently read economics_staging_dev; dbt actually materializes to economics_staging. It only worked because both happen to be backfilled right now. Re-verified entropy_complexity_job against live BigQuery post-fix — still succeeds (682 rows), now correctly reading economics_staging.

Added 6 unit tests locking in the precedence.