Feature request: Meta Ads attribution window configuration

<!-- req-ref: 1786124803.790169 --> ## What & why The Meta Ads data warehouse source has no way to configure the attribution window used to compute reported conversions (`action_attribution_windows`) or whether to use Meta's unified attribution setting (`use_unified_attribution_setting`). Attribution-window choice materially changes reported conversion counts — a 7-day click / 1-day view window produces different numbers than 28-day click / 1-day view for the same underlying activity. Without a way to configure this on the source, numbers synced through this connector silently diverge from what's shown in Meta Ads Manager (and from any other tool reporting on the same ad account), breaking reconciliation between PostHog and Ads Manager, or between PostHog and any other historically-reported numbers. Other connectors to Meta's Marketing API (Extract, Fivetran) already expose this as connector-level config, so this is a known gap relative to comparable tools. ## Implementation plan - **Research findings**: `action_attribution_windows` and `use_unified_attribution_setting` are documented as parameters on Meta's Insights API request (the `/insights` edge used by this source's stats endpoints). See the breakdowns reference for how Insights API parameters are documented: https://developers.facebook.com/docs/marketing-api/insights/breakdowns — look for the sibling "Attribution Setting" / attribution-windows page under `https://developers.facebook.com/docs/marketing-api/insights/` for the exact parameter names, accepted values (e.g. `1d_click`, `7d_click`, `28d_click`, `1d_view`, `7d_view`), and Meta's own default behavior when the parameter is omitted. - **Pattern to follow**: this source's per-connection config lives in `products/warehouse_sources/backend/temporal/data_imports/sources/generated_configs/metaads.py` (a generated `MetaAdsSourceConfig` dataclass — do not hand-edit it), sourced from the field list declared in `get_source_config` in `products/warehouse_sources/backend/temporal/data_imports/sources/meta_ads/source.py` (see the existing `sync_lookback_days` `SourceFieldInputConfig` there for the pattern to copy). After adding a field there, regenerate the config with `pnpm generate:source-configs`. - **Concrete steps**: 1. Add a new optional config field (e.g. `attribution_windows` and/or `use_unified_attribution_setting`) to `get_source_config` in `source.py`, following the `sync_lookback_days` field's shape. 2. Regenerate `generated_configs/metaads.py` via `pnpm generate:source-configs`. 3. Thread the new config value through to the request builder in `products/warehouse_sources/backend/temporal/data_imports/sources/meta_ads/meta_ads.py`. All Insights (`is_stats`) requests build their `extra_params` from `schema.extra_params` merged with `level`/`time_increment` in `meta_ads_source()` — add the attribution parameter(s) there only when the field is set on `config`. 4. Default behavior when the field is unset must match Meta's own default for the Insights API (from the research above), not an arbitrary window PostHog picks — this preserves current behavior for existing connections. 5. Tests in `products/warehouse_sources/backend/temporal/data_imports/sources/meta_ads/test_meta_ads.py`: assert the attribution parameter is sent on the Insights request when configured, and that an unset config produces the exact same request as today (backward compatibility). - **Open questions/risks**: - Whether this should be a single connection-level setting (one attribution window for every stats table) or needs to vary per-table/per-breakdown-endpoint — flag as a design decision if unclear from research, since the connection-level fields declared in `get_source_config` currently apply uniformly across all of a connection's tables (see `sync_lookback_days`, which already works this way). - This shares scope with the sibling "ad/adset-level breakdowns" P0 issue filed separately — both touch Insights API request construction in `meta_ads.py`, so implementation of one should be checked against the other to avoid conflicting changes to the same request-building code path.