Counting points on a given irregular grid that are inside or outside a circle
Well, you are manually testing every point \$(X_i, Y_j)\$ to see where it falls. You shouldn't, really.
Remember the sage advice: If in doubt, sort.

A better algorithm goes:


Read all X-coordinates.
Change them to squared distance from center-line.
Sort them.
Read an Y-coordinate.
Calculate the squared-distance from center-line for X-coordinates leading to the point sitting on the circle. \$\Delta x^2 = r^2 - (y - r)^2\$
Use binary search to determine how many elements from point 3 are smaller/equal/greater than the target.
Repeat at 4 until done.


Your algorithm was \$O(n \cdot m)\$. This one is \$O((n + m) \cdot \log(n))\$.

As an aside, if you simply double the given coordinates before processing them, you don't have to insist on the largest being even.



Now let's take a look at your code:


unsigned only has a minimal maximum of \$2^{16}-1\$, less than \$10^7\$. Even if it had 32 value-bits as on most desktops, \$2^{32}-1\$ is still below \$10^{14}\$. So, use long long which has a guaranteed 64 value-bits.
Why do you use double as the result of distance_squared()? If you did the calculation with double it would be accurate, though slow, but you only convert implicitly on return, which is far too late to help.
An unsigned is cheaply copied. Passing it by constant reference is actually a pessimization, luckily the optimizer will inline it so no harm done.
return 0; is implicit for main().
You should always finish your output with a newline. Not doing so means the prompt after calling the program won't be on a new line, and on ancient systems could have even less desirable outcomes.
The one time you use continue; it doesn't actually have any effect.
Some people like putting single-statements on the same line as the corresponding if, else if or else. I would desist as it impairs readability.
All else being equal, try to define any variable in the smallest scope you can, so a reader doesn't have to trace it all over the place. Concentration is a resource best preserved where possible.
inline only has the effect of allowing multiple equivalent definitions left. If it's only used in the current TU, better mark it static to get internal linkage.
Also consider defining a function before its use so you don't have to add a separate declaration. Remember, don't repeat yourself (DRY).
Restrict line-length so there's no horizontal scrolling. Horizontal scrolling, especially couple with vertical scrolling, is the bane of readability.