refactor(uffd): extract safeInvoke helper

[ValentaTomas]

Summary

• Introduce a small `safeInvoke(fn)` helper in a new `invoke.go` that calls `fn` and returns its result, or `nil` if `fn` is nil.
• Use it in `faultPage`'s two failure paths, replacing the duplicated `if onFailure != nil { signalErr = onFailure() }` blocks.

Pure refactor, no behavior change.

Split out of #2419 alongside #2441 (Prefault extraction).

Test plan

• `go build ./...` passes
• `go vet ./pkg/sandbox/uffd/...` clean
• `golangci-lint run ./pkg/sandbox/uffd/...` clean

[cursor]

PR Summary

Low Risk
Low risk refactor: centralizes nil-checking around the optional onFailure callback without changing error paths or retry/copy behavior. Risk is limited to inadvertent differences in when/if the callback is invoked, but the new helper preserves the prior logic (nil => no-op).

Overview
Extracts a small safeInvoke(func() error) helper and uses it in faultPage failure handling to remove duplicated onFailure nil-check/invocation logic when joining and reporting errors.

^{Reviewed by Cursor Bugbot for commit cf2b55e. Bugbot is set up for automated code reviews on this repo. Configure here.}

[claude]

LGTM — straightforward deduplication with no behavior change.

Extended reasoning...

Overview

Adds a 3-line safeInvoke helper in a new invoke.go and replaces the two identical inline nil-check blocks in faultPage with calls to it. Only two files changed.

Security risks

None. The helper is internal to the package, touches only the error-path callback invocation, and introduces no new inputs or trust boundaries.

Level of scrutiny

Minimal scrutiny needed. This is a mechanical deduplication with provably identical semantics: safeInvoke(fn) returns nil when fn == nil and fn() otherwise, which is exactly what the replaced inline blocks did.

Other factors

No bugs reported, author verified go build, go vet, and golangci-lint all pass. The change is small, self-contained, and easy to audit by inspection.