Addresses the highest-priority item in #297 (G02/G03 arc routing).

Upstream dependencies:

• This PR depends on fix: support Excellon routing/milling commands (G00, G01, M15, M16, M17) #283 (Excellon route milling), which is already merged — it provides drill_add_route_segment(), the route_mode/tool_down state tracking, and the M15/M16/M17 tool up/down handling that this PR builds on for arc routing.
• This PR may have minor merge conflicts with feat: implement Excellon G87 routed slot canned cycle #300 (G87 routed slot) in the G-code dispatch switch in drill.c, since both add cases in the same region. Whichever merges second will need a trivial rebase.

Yes, I will probably need information in what order you have thought all your PRs should be merged? I will check all your PRs in the coming days and drop comments.

Comments for future updates

1. Code duplication — calc_cirseg_mq and calc_cirseg_bbox re-implemented verbatim

Both are static in gerber.c so they can't be called from drill.c. The PR duplicates:

• Full body of calc_cirseg_mq() (~30 lines of math + comments)
• Most of calc_cirseg_bbox() (~25 lines) reimplemented inline in the bbox block

If a bug is ever found in calc_cirseg_mq, it needs fixing in two places. The correct structural fix is to move both functions to a shared location (e.g., gerb_image.c) and export them. That's a larger refactor — acceptable to defer, but worth a TODO comment or a follow-up issue.

2. Bounding box uses floor() — differs from calc_cirseg_bbox but is actually more correct

The PR's middle-point loop:

for (step_pi_2 = (floor(ang1 / M_PI_2) + 1) * M_PI_2; ...)

calc_cirseg_bbox in gerber.c uses:

for (step_pi_2 = (ang1/M_PI_2 + 1)*M_PI_2; ...)

For non-axis-aligned ang1 (e.g. 45°), gerber.c gives start = 1.5×(π/2) = 135° — which skips the 90° axis crossing. The PR's floor(0.5)=0 gives start = 1×(π/2) = 90° — which is correct (first axis crossing after 45°). The PR accidentally fixes a latent imprecision in the original bbox algorithm. No action needed here, but it's worth documenting.

3. delta_cp_x/y not reset on T-code tool change (drill.c:887)

case 'T':
    drill_parse_T_code(fd, state, image, file_line);
    state->route_mode = DRILL_G_DRILL;
    state->tool_down = FALSE;
    /* delta_cp_x/y NOT reset here */
    break;

In practice this is harmless — both fields are cleared after every arc segment and on tool-up, so by the time a T-code is seen they're already 0. But for defensive consistency with the route_mode/tool_down resets, adding state->delta_cp_x = state->delta_cp_y = 0; here would be better hygiene.

Great patch, will merge it and drop an issue for future reference.