UPDATE — April 25, 2026
Significant new findings after deeper DOM inspection. The block is no longer empty, but articles are rendered offscreen.
What changed since my last report:

Yesterday: the block container appeared completely empty — no child modules in the DOM.
Today (verified via browser DevTools): the container #tdi_96 now contains 5 .td_module_flex elements with correct titles, dates, categories, and links pointing to the right posts.
However, the articles are rendered at top: -4729px on the public frontend — far outside the viewport, which is why they remain invisible to users despite being present in the DOM.

Detailed observations from the frontend (incognito, logged out):

Articles ARE in the DOM: confirmed via document.querySelectorAll(‘#tdi_96 .td_module_flex’) returning 5 elements with valid content.
Articles positioned offscreen: getBoundingClientRect() returns top: -4729, left: 20 for the first article. Parent #tdi_96 itself sits at normal page position with height: 234px.
Computed CSS does not explain the offset: position: relative, top: 0px, marginTop: 0px, transform: none, translate: none, inset: 0px — no positioning rule should push the elements offscreen.
No transform on any ancestor: walked up the DOM from .td_module_flex to #tdi_96 — no element has a transform or non-default position.
In tagDiv Composer editor, the block displays correctly — all 5 articles visible with normal layout. The issue manifests only on the public frontend rendering.
Block class on frontend: td_block_inner td-mc1-wrap with el_class=”td-week-slider” set in shortcode.
Image container has display: none (intentional — image_floated=”hidden” in config).
Editor still throws 8x “model does not match content” errors when opening the Homepage in tdc. These persist from yesterday and have not cleared.

Hypothesis:
The block appears to enter a ticker/slider rendering mode on the frontend (consistent with the td-week-slider class), where articles are positioned offscreen waiting for a JS animation that never executes. The editor renders the block correctly because it bypasses this ticker behavior, but the frontend runtime applies it and fails. This may be linked to the persistent “model does not match content” errors.
Concrete questions:

(a) How can I force this block to render as a standard vertical flex list (no ticker behavior) without entering Composer to edit it (since opening the Homepage in tdc shows the model errors)?
(b) Is there a way to clear the model-content mismatch from the database directly (wp_options, wp_postmeta) without going through the editor?
(c) Does the td-week-slider el_class trigger specific JS that could fail silently and leave articles parked offscreen?

I can provide additional diagnostic output from DevTools console if helpful.