v2.0.1

2.0.1 — tracks -H tolerates unnamed tracks

Patch release. One bugfix, no API changes, no new verbs. tracks -H no longer
crashes on drafts containing tracks written by other tools.

The bug it fixes

track.name is optional on disk: tracks created by cutcli audios add /
cutcli videos add (and potentially CapCut itself) carry no name field. The
Track interface declared it required (name: string), so the unguarded
t.name.padEnd(…) in the -H table formatter passed the compiler and crashed at
runtime on the first unnamed track:

$ capcut-david tracks "<draft>" -H
{"error":"Cannot read properties of undefined (reading 'padEnd')"}   # exit != 0

The JSON output had the same root cause in a quieter form: the name key was
silently absent for those tracks.

Found on a real production draft (Stickman A/B rire-de-tout_AB-A, 2026-07-12):
a cutcli-created SFX track and a cutcli-created video track, both unnamed.

Highlights

• 🔧 cmdTracks normalizes name to "" (t.name ?? "") at the data-map level —
  one guard covers both the -H table and the JSON output.
• 🧬 Type honesty: Track.name?: string — the compiler now rejects any future
  unguarded string use. All other track.name uses in src/ are === comparisons
  (undefined-safe, unchanged).
• 🧪 499 tests (+1 regression: unnamed track renders in -H, exit 0, JSON
  name === ""). Typecheck clean.

Migration

None. Read-only inspection path; no draft output changes — the byte-identity
contract (v1.3.0) is untouched.

Compatibility

• CapCut ≥ 5.x desktop (Windows + macOS) — unchanged.
• Node >= 18 — unchanged.
• Runtime dependencies: zero — unchanged.