Lem-in: Shortest Path Isn't Always the Goal

My team just started lem-in, the next project after Groupie Tracker. You've got a colony of rooms and tunnels, a pile of ants at ##start, and the job is to get them all to ##end as fast as possible. My first thought was "easy, just BFS for the shortest path." Turns out that's the wrong instinct.
Say the shortest path is 5 rooms long and you've got 50 ants. Send them all down that one path and they queue up single-file, taking way more turns than you'd think. But if there's a second, slightly longer path, running ants down both at once clears the colony faster overall. So the real goal isn't the shortest path, it's the fewest total turns, which means finding multiple paths and splitting ants across them smartly.
There's a catch too: each room (except start/end) can only hold one ant at a time, so the paths can't share rooms in the middle. That turns this into something closer to a max-flow problem than a simple shortest-path one.
Right now, before writing any code, my teammate and I are splitting it: one of us on parsing and validating the colony file (there are a surprising number of ways it can be malformed), the other on path-finding and ant scheduling. Going to write a follow-up once we've actually got it running, because I suspect this mental model is about to get tested.