docs(skills): fork workflow — capture the fork id too; delete by fork id

Author: eddietejeda

skills/hotdata/references/WORKFLOWS.md

@@ -139,11 +139,11 @@ Before destructive experimentation (bulk replaces, schema rework, testing a load
 ```bash
 hotdata databases list                    # note the source database id (dbid...)
 hotdata databases set <source_id>         # source to protect (`set` takes an id)
-hotdata databases fork --expires-at 24h   # deep copy; becomes the active database
+hotdata databases fork --expires-at 24h   # deep copy; becomes the active database — note the fork id it prints
 hotdata databases load --catalog sales --table orders --file ./risky.parquet  # hits the fork
 ```
 
-**Capture the source database id up front.** After the fork, both databases answer to the same catalog alias (here `sales`), so the id is the only unambiguous way to refer back to the source. The shared alias means experimental SQL runs unchanged against the fork. Attached connections are re-attached to the fork; indexes are not carried over. When done, keep the fork (`databases set <source_id>` to switch back to the source) or `databases delete` it. Only DuckLake-backed databases can be forked — see `fork` in the main skill for details.
+**Capture both ids.** After the fork, both databases answer to the same catalog alias (here `sales`), so ids are the only unambiguous way to refer to either one — the source id comes from `databases list` up front, the fork id from the `fork` output. The shared alias means experimental SQL runs unchanged against the fork. Attached connections are re-attached to the fork; indexes are not carried over. When done, keep the fork (`databases set <source_id>` to switch back to the source) or delete it (`databases delete <fork_id>`). Only DuckLake-backed databases can be forked — see `fork` in the main skill for details.
 
 ---