refactor: one resync path in send and the SNMPv3 negotiation in its steps

[ilyam8]

Summary

Restructures send, the request boundary, and the SNMPv3 negotiation. No behavior or exported API change.

send handled the two Reports that resynchronize the client (notInTimeWindow, unknownEngineID) in two copies of the same branch, and recognized them with its own switch beside the table answers used.

• reportKinds (replacing reportErrors): each Report counter gives the request's error, whether it resynchronizes the client, and its name in log lines; reportKindOf serves both answers and send.
• send keeps the boundary (recover, the Conn and Retries checks, the negotiation) and resynchronizes in one paragraph: update the packet, send it again, return the Report's error if that fails. The retransmission stays in send on purpose: every result passes through its named results, which the recover returns when a panic (user code's included, such as a Logger) ends the request.
• negotiateInitialSecurityParameters either discovers the engine (discoverEngine, RFC 3414 section 4) or derives the keys; engineFoundDespiteUnknownUser names the tolerance for devices that answer discovery with usmStatsUnknownUserNames. Its guards stay: the client's Logger runs inside send before the negotiation and can change the client.

Each known bug of these functions keeps one site with a known-bug comment (setSecurityParameters, storeSecurityParameters and the discovery exception of testAuthentication included); the stale RFC 2574 comment is replaced.

The test commits pin what mutation probes and two reviews found unobserved, each passing on the previous code: a panic during the retransmission (from a hook or the Logger), hooks and a Logger that change the client, Reports answering the retransmission, a resync Report for another request ID, a discovery answer without an engine ID (AES, DES, MD5), and the engine time of the retransmission's answer (several of these are known bugs). BenchmarkGet and BenchmarkGetV3 run through send (BenchmarkSendOneRequest stops below it).

Testing

• go test ./... on darwin/arm64 and GOARCH=386; -race; the FIPS 140-only tests; golangci-lint v2.14.0 (incl. end2end): 0 issues; GOOS=windows go vet.
• Goldens unchanged by the refactor commits. Logger output unchanged: the engine suites rerun with a recording Logger (method, format, arguments) on the old and new code give the same 3081 calls.
• Mutation probes on the new code (56, plus 16 from review): all caught except 2 equivalent, 3 reachable only through user code changing the client mid-request, and 2 that change only the Logger call (caught by the Logger comparison).
• An independent equivalence review compared the old and new code side by side: every pinned scenario with and without a Logger, 800k random scenarios (v2c and v3, with Reports in the first and the retransmission's answers), a matrix of user-hook and Logger actions at every call point, FIPS 140-only, and loopback TCP. Its findings are fixed in this PR; no network-driven input differs.
• Interleaved A/B against the previous code: BenchmarkSendOneRequest, BenchmarkGet and BenchmarkGetV3 within noise, B/op and allocs/op identical.