Fix Smarkets resolutionDate fallback

[jordansilly77-stack]

Summary

• stop using start_datetime as a Smarkets resolutionDate fallback when end_date is missing
• stop defaulting missing Smarkets resolution dates to the current time
• add regression coverage for both missing-end_date paths

Context

I checked the Smarkets public events endpoint and the single-event endpoint while looking at #1366. Both can return end_date: null; for example, GET https://api.smarkets.com/v3/events/?limit=3&state=upcoming and GET /v3/events/{id}/ returned null end_date values for sampled events.

Since start_datetime is the event start time rather than a resolution time, exposing it as resolutionDate can make cross-venue sorting/filtering look more precise than the venue data supports. UnifiedMarket.resolutionDate is optional, so this now leaves it unset unless Smarkets actually provides end_date.

Tests

• npm test --workspace=pmxt-core -- --runTestsByPath test/normalizers/exchange-normalizers-2.test.ts
• npm run build --workspace=pmxt-core

[realfishsam]

PR Review: VERIFIED

What This Does

This changes the Smarkets market normalizer so resolutionDate is only populated from the venue end_date. If Smarkets omits end_date, PMXT now leaves resolutionDate unset instead of pretending the event start time (or the current clock time) is the market resolution time.

Blast Radius

Smarkets market normalization only: core/src/exchanges/smarkets/normalizer.ts and the Smarkets fixture coverage in core/test/normalizers/exchange-normalizers-2.test.ts. This affects fetchMarkets / event enrichment consumers wherever Smarkets markets are returned, including router sorting/filtering paths that rely on unified resolutionDate. No SDK shims, OpenAPI schema, auth, or generated files were changed.

Consumer Verification

Before (base branch):
Fixture-equivalent Smarkets raw data with end_date: null and start_datetime: "2025-05-01T09:00:00Z" normalized to a misleading resolution date:

node - <<'NODE'
const { SmarketsNormalizer } = require('./core/dist/exchanges/smarkets/normalizer');
// normalizeMarket({ event: { end_date: null, start_datetime: '2025-05-01T09:00:00Z', ... }, ... })
NODE

Observed response snippet on origin/main after build:

{
  "resolutionDate": "2025-05-01T09:00:00.000Z",
  "title": "UK General Election 2025",
  "marketId": "market-456"
}

After (PR branch):
The same consumer-path normalizer probe leaves the field absent/undefined when Smarkets has no end_date:

{
  "title": "UK General Election 2025",
  "marketId": "market-456"
}

The existing end_date path is still covered by the normalizer suite (sets resolutionDate as a Date from event end_date).

Test Results

• Build: PASS (npm run build --workspace=pmxt-core)
• Unit tests: PASS (npm test --workspace=pmxt-core: 797 passed, 3 skipped, 44 suites passed, 1 skipped)
• Server starts: PASS (GET /health returned {"status":"ok",...})
• E2E smoke: PASS for the local Smarkets normalization consumer path above; no live Smarkets HTTP smoke was required because the PR changes pure normalization and the fixture matches the fetcher raw type.

Findings

No blocking findings.

PMXT Pipeline Check

• Field propagation (3-layer): N/A — no unified type/schema/SDK field was added or renamed; this only changes whether an optional existing field is populated.
• OpenAPI sync: N/A — no BaseExchange/server schema signature changed.
• Financial precision: N/A — no price/amount math changed.
• Type safety: OK — helper returns Date | undefined, matching UnifiedMarket.resolutionDate?: Date; no new any or non-null assertions introduced.
• Auth safety: N/A — no credential or request-signing paths changed.

Semver Impact

patch -- bug fix to avoid emitting an incorrect optional resolutionDate for Smarkets markets that lack a venue resolution/end date.

Risk

The remaining production risk is venue semantics: this assumes Smarkets end_date is the only currently trustworthy resolution/cutoff field among the raw event fields. Markets without end_date will now sort/filter as having no resolution date; that is preferable to a fabricated start/current date, but consumers relying on every Smarkets market having a resolutionDate may need to handle the already-optional field.