∴ Thinking…

  THERE IT IS!!!

  pub fn affineCoordinates(p: Secp256k1) AffineCoordinates {
      const zinv = p.z.invert();
      var ret = AffineCoordinates{
          .x = p.x.mul(zinv),      // x = X * Z^{-1} !!!
          .y = p.y.mul(zinv),      // y = Y * Z^{-1} !!!
      };

  It's NOT X * Z^{-2}! It's X * Z^{-1}! This is PROJECTIVE coordinates, not Jacobian coordinates!

  So the stdlib is using weighted projective coordinates where the affine conversion is simply x = X/Z and y = Y/Z, not the Jacobian formula with Z^2 and Z^3 in the denominators. That
  earlier agent must have been mistaken about the Z^{-2} computation.

  For the signature verification, this means the Jacobian comparison should check r_fe * Z == X (mod p) directly, or (r_fe + n_fe) * Z == X (mod p) if there's an overflow. I need to verify
   the overflow boundary condition to make sure the check is complete. I need to check the paper more carefully—Algorithm 9 from eprint 2015/1060 is for complete point addition using
  homogeneous projective coordinates where x = X/Z and y = Y/Z, which matches what the code is actually doing with its affine conversion. So the affine conversion shows this is projective
  coordinates where x = X/Z and y = Y/Z, not Jacobian. I need to fix the verification logic to compute Z directly and check if r * Z == X (mod p) instead of using the Jacobian formula.

⏺ FOUND IT. The stdlib uses projective coordinates (x = X/Z), NOT Jacobian (x = X/Z²):

  .x = p.x.mul(zinv),    // X * Z^{-1}, NOT zinv2!
  .y = p.y.mul(zinv),    // Y * Z^{-1}, NOT zinv3!

  The earlier research agent hallucinated zinv2/zinv3. This is why zig zen says "favor reading code over writing code." The fix is trivial — multiply by Z, not Z².