Prebuilt write Requests bypass the default no-retry policy

Reproduction

On main at 1dbc37fd1ceab832fc7c90cad81b1091c95ba563, passing a prebuilt Request with a write method does not apply the default no-retry policy documented for POST, PUT, PATCH, and DELETE:

import { createFetch } from "ofetch";
let calls = 0;
const ofetch = createFetch({
  fetch: async () => {
    calls++;
    return new Response("unavailable", { status: 503 });
  },
});
await ofetch(new Request("https://example.test/", { method: "POST" })).catch(() => {});
console.log(calls); // 2, expected 1

The retry, request-body serialization and HEAD response-body guards inspect options.method only, although native fetch also takes the method from the Request input. The same discrepancy leaves an overriding JSON object body unserialized for a POST Request and attempts body parsing for a HEAD Request with a custom fetch implementation returning a body.

Six new regression cases fail against this commit: all four write methods, HEAD parsing, and JSON body serialization. GET retry, explicit retry opt-in, and explicit method override controls pass. A local HTTP server also reproduces the POST retry behavior.

Expected behavior

Use the effective method (resolved options first, then Request, then GET) for these three existing guards, including after an onRequest hook changes the Request. Do not change the explicit numeric retry opt-in or string-request behavior.

This is separate from #583, which changes FetchError message precedence. No error-message code needs to change for this defect.

Start at the method-dependent retry, request-body serialization, and HEAD response-body guards, then trace how the Request input and any onRequest hook affect the effective method. Reproduce the six described cases and confirm that method resolution uses options first, then Request, then GET without changing explicit retry controls or string requests.