feat: enable recording episodes into existent dataset

[JeronimoMendes]

This PR:

• extends the edit dataset page to support adding new episodes
• shows sync status with hf hub.
• deletes upload dataset page in favor of edit dataset.
• matches styling of components to the job page.

Demo

Disclaimer

AI tools such as Pi and Claude were used, specially on the frontend part of the PR, although I reviewed all of the code generated.

Closes #11

[nicolas-rabault]

Very nice PR @JeronimoMendes
A few simple modifications :

1. Dead code

The resume feature is driven entirely from EditDataset.tsx, which renders RecordingSettingsFields inline and calls rec.startRecording directly. It never uses RecordingModal. Consequences:

useRecording.ts:48 openForResume(...) is exported but never called anywhere.
The entire isResuming branch of RecordingModal.tsx is unreachable: the modal is only mounted in Landing.tsx, which always opens it via openForNew → resumeRepoId is always null there. So "Record More Episodes" / "Resume Recording" / the resume-repo display block / the "Append new episodes…" description can never render.
So the modal carries a resumeRepoId prop + branch and the hook carries an openForResume path that nothing exercises. Either wire the modal up for resume, or strip the resume branch from RecordingModal and drop openForResume. Given EditDataset already inlines the fields, the latter (delete) is the simpler, consistent choice.

2. Sync-status mtime comparison is fragile (medium)

handle_dataset_sync_status uses local_root.stat().st_mtime (top-level dataset dir) vs Hub lastModified. Two failure modes:

A directory's mtime only changes when a direct child entry is added/removed/renamed, not when files deep in data/chunk-*/ or videos/ are written, nor when an existing top-level file is rewritten in place. New episodes can land without the top-level mtime advancing, so needs_sync can be falsely False. The worst direction (UI says "in sync" when it isn't).
After a fresh download/clone from the Hub, local mtime = download time > hub_mtime, so it reports falsely needs_sync: True.
A more reliable signal would be a max mtime walk over the dataset tree, or reading the dataset's own episode count/revision metadata.

[JeronimoMendes]

Thanks a lot for the quick review @nicolas-rabault .

1. Totally right about that, should be fixed now.
2. Thought about this and reached the conclusion that a simple file count might not be enough (I'm already thinking in the future with a possible episode deletion feature 😉, where a delete followed by a new episode would be considered "synced" with the hub). In fact, this is a far more complex issue than what this feature branch calls for because to truly be in sync with the Hub we need to consider pushes and pulls from the hub. To keep it simple, I've changed it so that we compute the local manifest (files + sizes) and match it against the one on the hub whilst still keeping the local dataset as the reference. Full bidirectional sync seems out of scope for this branch, let me know what you think!