Good news, OSHPARK issued a refund for the defective boards I ordered from them. They seem to have figured out the problem and have a fix for it. This is what they said, and they asked me to also relay this information to the forum:
"Some additional info for you here. Since you're active on the forum, if you want post the following, it might help some users understand this issue here. Seems that the board suddenly got popular, so while we're resolving things now it seems the "forum" is as impacted as much as any one user.
The specific problem is deterministic based on the design, but the conditions to force it are extremely rare (an arc with a length of 0.000001 and 0.000004 inches). As a result, this problem will impact a bunch of people who've ordered the SDRAM boards, but no one else would be affected. Other than this one board, we haven't seen this issue occur in the two years since we previously submitted patches for the base problem.
In the near term, we're going to flag all these boards as they come in so we can swap in corrected files. Long term, we just have to patch one more software package, which should be pretty quick.
So, the technical detail for the failure is how arcs are treated in gerber viewers, and how some software handles this.
Internally, gerbers have arcs represented as 3 points: A start point, a centerpoint offset, and an end point. Gerber circles are represented the exact same way, only the gerber spec simply states to have the start and end point be the same. The upshot of this file format decision is that if a gerber ever loses precision on the coordinate data, it's possible to convert arcs of an extremely small length to a zero length, which in turn converts it to a full circle. This has to be precisely mitigated by either A) Never changing the format precision to a lower value, or B) Carefully tracking any arcs and avoiding this drop.
There's also some specific gerber commands that are intended to prevent this conversion through single or multi-quadrant arc specifications, but they tend to be less robust in how they're interpreted in practice. We've seen this exact issue come up in several software packages, including our fab's production equipment and processing tools.
Over the years we've patched a bunch of software to avoid this gracefully (allowing precision loss without causing arc wrapping). However, apparently we missed one software tool which is still is using 3.5 format instead of 3.6, which generates a precision loss of 1 digit. This means arcs that are between 0.000001 to 0.000004 inches in length, _and_ does not cross value of 0.000005 (which would cause them to round them to different values), can get converted to full circles.
Hopefully this helps explain the issue, and we encourage anyone affected to contact us for replacements and/or refunds. We really dislike bugs like this impacting our users, so we're happy to help correct things however we can."