- Set taskType="sync" on Fivetran pipeline tasks
- Implement yield_pipeline_status() to derive execution history from
  succeeded_at/failed_at timestamps in connector details
- Add failed_at to mock dataset for test coverage
- Add tests for task type, status with both/one/no timestamps

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

…phases, and lineage fixes

The Fivetran REST API sync-history endpoint has very limited retention
(entries age out within hours). This change queries the destination
warehouse's fivetran_metadata.log table directly for comprehensive sync
history with accurate per-phase timing, falling back to the REST API
when the destination DB is unavailable.

Key changes:

Destination DB sync history:
- Resolve the destination warehouse's DatabaseService from the service
  registry using the existing dbServiceNames lineage configuration
- Query fivetran_metadata.log table with sqlglot-generated quoted
  identifiers (dialect-aware for Snowflake uppercase, Postgres lowercase)
- Parse LOG events (sync_start, extract_summary, write_to_table_start/end,
  sync_end, sync_stats) to derive per-phase timing and status
- Graceful fallback to REST API on any failure (unsupported destination
  type, missing service, query error)
- Time-bounded queries (90-day retention) to avoid unbounded fetchall()

ELT task phases (Extract → Process → Load):
- Replace single "sync" task with three distinct pipeline tasks
  representing Fivetran's ELT phases
- Each task has independent timing and status derived from LOG events
- sync_stats durations used as fallback when intermediate events are
  missing (e.g., incremental syncs with no data changes)
- Task DAG wiring via downstreamTasks for UI rendering

Lineage fixes:
- Fix service name fallback: change `or "*"` to `or []` to prevent
  building FQNs with literal "*" as service name
- Resolve pipeline entity once per connector instead of per-table (N+1)
- Fetch destination details once per group instead of per-connector (N+1)
- Support messaging sources (Kafka, Confluent Cloud) with topic lineage
- Column-level lineage via Fivetran schema API
- Self-lineage prevention (source == destination entity)

Client robustness:
- Add null/type guards to run_paginator for None API responses
- Fix get_connector_details/get_destination_details to return {} instead
  of None on failure
- Fix base64 token encoding to use .decode("ascii") instead of str()[2:-1]
- Fix type annotation from Optional[Response] to Optional[dict]
- Remove unused Response import

Other improvements:
- Display name shows source first: "postgres <> Snowflake"
- Task type "Process" (not "Transform") for the processing phase
- sourceUrl only on Pipeline, not on individual Task objects
- Add copyright headers to models.py and service_spec.py
- Add return type annotations to model properties
- 34 unit tests covering DB query path, fallback scenarios, lineage
  resolution, column lineage, and task status building

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

…ure, schedule interval edge cases

- Add null guard after pipeline_entity resolution in lineage yield to
  prevent AttributeError crash when pipeline entity is not found
- Cascade extract failure to process/load status instead of reporting
  false success when write events or sync_stats timestamps exist
- Handle non-hour-divisible schedule intervals (e.g. 90 min) and clamp
  values >= 24 hours to daily cron
- Add 5 tests covering all three fixes

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

…ange

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

- Add isinstance(response, dict) guards in get_connector_schema_details
  and get_connector_column_lineage, consistent with get_destination_details
- Replace datetime.utcnow() with datetime.now(timezone.utc) for Python 3.12+

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

…me fallback

- Add parentheses around messagingServiceNames to fix operator precedence
  when lineageInformation is None
- Use (dict.get("config") or {}) pattern to handle explicit null values
  from the Fivetran API without AttributeError
- Use tz-aware datetime.min fallback in sync sorting to avoid TypeError
  with tz-aware DB timestamps

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

- Filter _resolve_destination_service by dest_service_type to avoid
  resolving to the source database service instead of the destination
- Mark process_status as Successful for zero-change incremental syncs
  where extract succeeds and sync_end is SUCCESSFUL but no write events

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

…tests

- Revert out-of-scope topology_runner.py change (Harsha)
- Remove UNSUPPORTED_DESTINATION_TYPES — Fivetran Platform Connector
  is available on all destinations including Databricks
- Move FIVETRAN_STATUS_MAP and HISTORICAL_SYNC_FIELDS to module level
- Replace sqlglot + raw SQL with SQLAlchemy MetaData.reflect() and
  select(), use yield_per(100) for OOM protection
- Extract _try_parse_json helper to reduce nesting in _parse_sync_events
- Standardize StatusType enum usage (remove .value calls)
- Fix operator precedence in get_db_service_names/get_storage_service_names
- Add unit tests for schedule interval edge cases, malformed JSON,
  multi-sync parsing, fallback task statuses

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Remove TestRunStageProcessorErrorReporting test class since the
corresponding topology_runner.py status.failed() change was reverted
as out of scope for this PR.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Co-authored-by: harshach <38649+harshach@users.noreply.github.com>

…tran_improvements