perf: revisit `epi_slide_opt_archive_one_epikey` interface

Consider whether `epi_slide_opt_archive_one_epikey` should:
- Accept a `data.table` rather than a `tibble`, and use the fast nesting operation `DT[, list(SD = .SD), keyby = ]`. (This moves us away from potential generality, though, as tibbles would let us group by packed tibble keys. https://github.com/Rdatatable/data.table/issues/1736 also may impact any changes inside of the function we might make.)
- Not rbind itself, but leave that to the parent function, which may be able to take the resulting lists of tibbles and double-unchop more efficiently (not forming as many medium-size intermediate non-epikey column results). Consider also in parent function whether `group_modify` should be replaced by `group_map` and special logic used to prevent forming as many medium-size intermediate epikey column results.

Start by locating epi_slide_opt_archive_one_epikey and its parent function, then read how they currently group and combine epikey results. Compare the proposed data.table nesting, rbind placement, and group_modify versus group_map options, including the implications of data.table issue 1736. Done means the interface and parent-function approach are decided and documented with supporting performance evidence.

Written by the indexing model from the issue text.