Event Details block is tense-blind: expose event timing + adapt past-event CTA hierarchy

[chubes4]

Summary

The Event Details block (inc/Blocks/EventDetails/render.php) renders identically for past and upcoming events, except for whatever a consumer derives on its own. On a show that already happened, the page still leads with a live "Get Tickets" / "Event Link" button (first in the action row, links out to the ticket vendor) and a fully-functional "Add to Calendar" dropdown. Nothing signals the event is over.

This matters because — on Extra Chill — ~60% of all events-site pageviews land on past-event pages (measured: 4,570 of 7,564 pageviews over 14 days), driven by post-show / long-tail search. So the single most-viewed event-page state is the one where the primary CTA (buy tickets for a finished show) is useless, and the genuinely useful action (log attendance) is unsupported by the layout.

Evidence (rendered past-event page)

Walked a live past event (Darius Rucker @ Pine Knob, start 2026-06-27T16:30, viewed after it passed):

• Date renders as a plain 📅 June 27, 2026 — no past-tense label, no "this show has passed," no visual treatment.
• event-action-buttons, in order: (1) "Event Link" ticket button (live, → Ticketmaster), (2) attendance button, (3) Add to Calendar dropdown, (4) Share.
• The ONLY past-aware signal anywhere on the page is a consumer-supplied attendance button whose label flipped to "I Was There" — and it sits below the dead ticket link.
• "Add to Calendar" (Google/Outlook/Apple/.ics) renders in full on an event that already happened.

The layer gap (this repo)

data-machine-events is the generic, network-agnostic layer and must not know about any specific site's attendance/retention features. But it currently withholds the one fact consumers need to adapt: event timing (past / ongoing / upcoming).

1. The block computes the start datetime but never derives or exposes timing. render.php has $start_date/$start_time but no is_past / timing concept. Every consumer re-derives it independently (e.g. Extra Chill's ec_users_get_event_timing() re-queries the event-dates table), which is duplicated work and drift-prone.

2. The data_machine_events_action_buttons hook passes only $post_id, $ticket_url. Consumers that want to reorder/adapt by tense have to re-query timing themselves. The hook should also pass event timing so consumers can compose tense-aware UI without re-deriving it.

3. The block's own ticket + add-to-calendar CTAs don't adapt to past events. For a past event, the ticket button should be de-emphasized or suppressed (filterable), and add-to-calendar hidden — generically, since this is correct for ANY consumer, not just Extra Chill.

Proposed scope (generic only)

• Compute event timing once in the block render (past | ongoing | upcoming) from the start/end datetimes already available.
• Pass timing into data_machine_events_action_buttons (new arg) and into data_machine_events_after_price_display, preserving existing args for back-compat.
• Add a filter (e.g. data_machine_events_show_ticket_button / data_machine_events_show_add_to_calendar) defaulting to hide/de-emphasize on past timing, so the generic default is sensible and sites can override.
• Optionally expose a small public helper (data_machine_events_get_timing( $post_id )) so consumers stop re-querying the dates table.

Explicitly out of scope for this repo: anything about concert attendance, "I Was There", the concert archive, or import — that lives in the Extra Chill consumer (extrachill-users), tracked in a companion issue. This repo only needs to (a) know and share tense, and (b) make its own ticket/calendar CTAs tense-aware.

Companion issue

Extra Chill consumer-side composition (attendance-first past-event layout, import-at-intent nudge, "who was there") will be filed against extrachill-users and depends on the timing exposure from this issue.