d-cores crash through Network/CLI (Component built with wrong field names) and use the older algorithm

Found by the September 2026 comparison against the C++ sources (see docs/migration-from-cpp.md on branch docs/legacy-heritage (PR #17)).

```
lanet-vi visualize --input d.txt --directed --decomp dcores --output d.png
ValidationError: 1 validation error for Component
component_id Field required
```

`decomposition/dcores.py` `find_components_by_dcore` (~lines 227-232) passes `id=`/`index=` to `Component`, whose fields are `component_id`/`index`. `Network.decompose(DCORES)` always calls it, so the whole d-core path is broken; `tests/test_dcores.py` only exercises `compute_dcores`.

Also: `compute_dcores` implements independent in-cores and out-cores per node, which is the older `graph_dcores_old.cpp`. The later `Source/graph_dcores.cpp` computes, for each out-threshold l, the in-core number k of every node in the (0,l)-out-core (a per-l table written to `dcores_list.txt`). Decide which definition the package should offer (possibly both) and fix the docstring that claims a port of `graph_dcores.cpp`.

Start with decomposition/dcores.py, Network.decompose(DCORES), and tests/test_dcores.py, then compare the documented behavior with docs/migration-from-cpp.md and the referenced C++ sources. Confirm the intended d-core definition, make the CLI path work, extend coverage beyond compute_dcores, and update the docstring to match the chosen behavior.

Written by the indexing model from the issue text.