fix: read a request's configuration once and never write it

[ilyam8]

Summary

Third step of the bug-fix phase: a request reads its configuration once, at its start, and never writes it.

The engine used to read the client's configuration live during a request:

• Retries and ExponentialTimeout at each retry decision, the Context at each attempt, and Transport for the TCP
  reconnect;
• the hooks at each call;
• the client's version and security model, in three guards that compared the client with the packet.

So a hook or the Logger that changed the client changed the running request. With the version changed after the
negotiation, the request went out with msgID 0.

The library also wrote configuration as working state:

• A request clamped a negative Retries to 0.
• Connect appended the IPv4/IPv6 suffix to Transport on every call, so a second ConnectIPv4 dialed "udp44", and
  narrowed it to IPv4 for an IPv4 local address.
• Connect reseeded the ID counters. This discarded SetRequestID/SetMsgID and made a second Connect replay the
  same IDs.

A client given a Conn without Connect panicked, for want of a Context and a receive buffer.

Now:

• send builds one request configuration: the retries (a negative value counts as 0), the timeout, the exponential
  timeout, the Context (a background one when the client has none), the network and the hooks. It allocates the
  receive buffer the first time. The engine reads only this configuration and the packet.
• The packet answers the version, security level, model and context:
  • the guards are gone;
  • the msgID follows the packet's version;
  • discovery takes the packet's context name;
  • the reply-model check compares the reply with the request.
• The ID counters start at a random value on first use, unless SetRequestID or SetMsgID set them. Connect leaves
  them alone.
• Connect derives the network (suffix, IPv4 narrowing) and records it with the connection it opened, which a request
  uses only while Conn is that connection. Transport is left as set. Connect still fills in its documented
  defaults: "udp", MaxOids, a background Context and Reportable.
• Three things are not read once, and the docs name them:
  • the Logger;
  • the SNMPv3 engine state the client learns;
  • the TCP reconnect, which dials with the client's Target, Port, LocalAddr and Control at that moment. A later
    step rewrites it with the connection's ownership.
• The random start of the ID counters is below 2147483647, so the first ID is never 0, which a Response may carry for
  any request.

Behavior changes:

• A hook's or the Logger's change to the client applies from the next request.
• Retries and Transport keep the caller's values.
• IDs survive Connect, and so do SetRequestID/SetMsgID. A client that never connected draws random IDs.
• A Conn given without Connect works, provided the caller sets the fields Connect would have filled in
  (MaxOids, for one).

Tests

• First commit: four scenarios where OnRetry changes Retries, ExponentialTimeout, the Context or a hook,
  pinning the old behavior.
• Golden flips:
  • the requests over a Conn without Connect succeed;
  • the hook scenarios no longer affect the running request (now including replacing every hook, and a Logger that
    changes the context name);
  • the SNMPv3 hook cases complete;
  • a negative Retries keeps its value.
• TestConnect records the derived network next to Transport. TestRequestAndMsgIDs pins the new counter rules,
  each counter's random start on its own.
• A real-socket test sends a request over a TCP Conn the caller set, without a Context, with a hook that changes
  Transport. It covers a client that never connected, one that connected over UDP and closed, and one whose
  connection was replaced. The request still reconnects over TCP each time.
• From the reviews:
  • every request scenario records the configuration fields its run changed, so a write by the library would show next
    to the hooks' own;
  • SNMPv3 scenarios where the discovery and the resync exchanges' hooks change the client;
  • a hook that sets a Context with a deadline.

Validation

• Local: golangci-lint, race tests, FIPS 140-only, six cross-builds, govulncheck and netsnmp playback pass.
  GOARCH=386 and the end-to-end suite run in CI.
• Benchmarks:
  • allocations and bytes are unchanged;
  • Get costs about 21 ns more per request (+2.7% on the in-memory benchmark), for building and copying the
    configuration;
  • that is a fixed, allocation-free cost against a network round trip.
• 33 mutants of the changed code: all killed but one with a 2^-31 effect.
• Two independent reviews (correctness of the invariant; test integrity and docs). They found a stale network after
  Close (fixed), an unpinned per-counter random start, gaps in the coverage of the "read once, never write" rule
  (closed), and docs that needed to name their exceptions.