Implement reusable knockout spider component in DCAR

## Summary

The purpose of this issue is to build a reusable knockout spider component in DCAR that can support major tournament knockout structures without requiring us to revive and adapt the [existing bespoke implementation ](https://github.com/guardian/frontend/pull/28737) every time.

This issue is focussed on the frontend component and the data/configuration pipeline it needs. It covers the "plumbing" needed for future editorial configurability, but not the tooling work itself.

Note: We should ensure the existing component has been through a design review prior to picking up this issue.

## Why

Currently, we rely on an existing knockout spider implementation that needs to manually be revived / modified and tested ahead of major tournaments. We want to remove this repeated engineering overhead and give editorial colleagues the tools they need to cover major tournaments without having a dependency on engineering.

For World Cup 2026, we pragmatically decided to revive the existing implementation to ensure we have something ready for kick-off. But longer term, we want to move the spider into DCAR as a reusable, editorially configurable component.

The next step is therefore to build the DCAR component with a clear data/configurability architecture, so that tooling integration can be added later by appropriately resourced teams/missions.

## Scope

Implement a reusable knockout spider frontend component in DCAR that can:

* Support knockout-style structures
* Render different numbers of stages and fixtures
* Handle pre-tournament placeholder teams, confirmed teams, scores, match status and match comments
* Work across our supported breakpoints
* Act as a foundation / contract for data / configuration that editorial tooling can integrate with
* Document any assumptions / limits related to editorial configurability

The implementation should separate:

* The frontend presentation of the component
* The data/configuration shape it consumes
* Any future editorial tooling needed to manage / configure the component

## Out of scope

* Implementing configurability via editorial tooling
* Changes to Composer / other editorial systems
* A full tournament/bracket tool
* Speculative tournament formats without a clear need / editorial intent
* Configuration by editorial users (for this phase)

## Deliverable

A reusable knockout spider component built in DCAR, with a documented data/configuration foundation that can later be wired into our editorial tooling.

## Acceptance criteria

* A reusable knockout spider frontend component exists in DCAR
* The component can support knockout-style structures
* The component is not tightly coupled to a single tournament structure / length
* The component consumes a clear and documented data / configuration shape
* The component includes the frontend plumbing needed for future tooling integration where possible / based on assumptions
* The component renders as expected across different breakpoints
* Assumptions / limitations are documented
* Expected / assumed future tooling work is clearly documented but not implemented as part of this issue