fix: preserve hooks for added writer interfaces

[felixge]

Follow-up to #33.

#33 added support for io.StringWriter and FlushError, but those new interfaces changed method dispatch in ways that could bypass existing hooks:

• io.WriteString preferred WriteString, bypassing an existing Hooks.Write interceptor when no Hooks.WriteString was configured.
• http.ResponseController.Flush preferred FlushError, bypassing an existing Hooks.Flush interceptor when no Hooks.FlushError was configured.

This preserves the previous hook behavior by routing the new interface methods through the older hook when only the older hook is configured. For the FlushError fallback, the old Flush hook wraps the underlying FlushError call so the returned error is preserved.

Hook behavior after this change

Wrap(w, hooks) still only exposes optional interfaces that w already exposes. Hooks do not add new capabilities.

General rule:

• For each method, the exact matching hook wins.
• If no exact hook is configured, most methods call the underlying method directly.
• The hook chain is prepared once during Wrap, not rebuilt on every method call.

Normal http.ResponseWriter methods:

Call	If hook is configured	Otherwise
Header()	Hooks.Header	w.Header()
WriteHeader(code)	Hooks.WriteHeader	w.WriteHeader(code)
Write(p)	Hooks.Write	w.Write(p)

Optional methods follow the same exact-hook rule for Flush, FlushError, CloseNotify, Hijack, ReadFrom, SetReadDeadline, SetWriteDeadline, EnableFullDuplex, Push, and WriteString.

Compatibility fallback for WriteString when the underlying writer implements io.StringWriter:

Hooks configured	WriteString("x") behavior
WriteString	Calls Hooks.WriteString
only Write	Calls Hooks.Write with []byte("x")
both Write and WriteString	WriteString wins; Write is not called automatically
neither	Calls underlying w.WriteString("x")

If the underlying writer does not implement io.StringWriter, the wrapper does not either, so io.WriteString(wrapped, s) falls back to Write([]byte(s)) and Hooks.Write applies as before.

Compatibility fallback for FlushError when the underlying writer implements both http.Flusher and FlushError:

Hooks configured	FlushError() / ResponseController.Flush() behavior
FlushError	Calls Hooks.FlushError
only Flush	Calls Hooks.Flush, whose next calls underlying FlushError; returns the underlying FlushError error
both Flush and FlushError	FlushError wins; Flush is not called automatically
neither	Calls underlying FlushError()

If the underlying writer only implements http.Flusher, ResponseController.Flush() uses Flush(), so Hooks.Flush applies. If it only implements FlushError, Hooks.Flush cannot apply because there is no Flush() method to wrap; use Hooks.FlushError.

Tests added for both regressions, including preserving the underlying FlushError error through the Flush compatibility fallback.

Validation:

go test ./...

[boekkooi-impossiblecloud]

I wonder if we should use the old hook behaviour in this case so we can actually return the error.

Something like:

state.flushError=func() (errerror) {
hooks.Flush(func() { err=t1.FlushError()
})()
returnerr
}