SEP 28: Check for slug collisions

✅ SEP 14: UUID collision checking addressed the risk of UUID collisions but the issue of slug collision still remains.

At time of writing, of the 344 documents on the site, 265 of them have a datetime derived slug (eg. 2023/04/11/101358) and are therefore safe from collision. Still, that leaves roughly 25% of documents in an unchecked namespace where collisions theoretically could occur, with the only thing currently preventing that being my ability to remember if I’ve used a particular slug before. At the current scale of the site there are no such collisions but as the site grows to a thousand and ultimately multiple-thousands of documents the likelihood of inadvertently reusing a slug will move from unlikely, to probable, to certain.

Checking for slug collisions at build time would be computationally cheap and easy to implement.

Long term, as the number of documents scales ever higher, it could make sense to perform this check using a tree structure but for now a simple dictionary will suffice.