Add fuzz testing with CI and fix snapshot ID panic

[arska]

Summary

• Add Go native fuzz tests for 3 targets that process untrusted input
• Fix a real panic found by fuzzing: snapshot.ID[:8] crashes on IDs shorter than 8 chars
• Add CI workflow that runs each fuzz target for 60 seconds on PRs and pushes

Bug found and fixed

filterAndConvert() in restic/kubernetes/snapshots.go:103 used snapshot.ID[:8] without checking length. If restic ever returns a snapshot with an ID shorter than 8 characters, the operator panics. Fixed by checking length before slicing.

Fuzz targets

Target	Package	What it tests
FuzzFilterAndConvert	restic/kubernetes	Snapshot ID processing from restic output
FuzzBackupOutputParser	restic/logging	Restic JSON backup output parsing
FuzzJsonArgsArrayUnmarshalJSON	operator/utils	Custom JSON unmarshaling of string-or-array

CI integration

Each fuzz target runs for 60 seconds in parallel via matrix strategy. Short runs catch regressions; longer runs can be done locally (go test -fuzz=... -fuzztime=5m) or via oss-fuzz.

Running locally

# Run a specific fuzz target for 5 minutes
go test ./restic/kubernetes/ -fuzz=FuzzFilterAndConvert -fuzztime=5m

# Run all fuzz targets briefly
go test ./restic/kubernetes/ -fuzz=FuzzFilterAndConvert -fuzztime=30s
go test ./restic/logging/ -fuzz=FuzzBackupOutputParser -fuzztime=30s
go test ./operator/utils/ -fuzz=FuzzJsonArgsArrayUnmarshalJSON -fuzztime=30s

Test plan

• Fuzz tests find the snapshot ID panic (seed corpus)
• Fix passes 15+ seconds of fuzzing with no crashes
• All three fuzz targets run cleanly locally
• CI workflow runs successfully

🤖 Generated with Claude Code

[tobru]

@Kidswiss mind giving this a review? I think it's OK, but I need another eye.

What I'm also unsure of is if the commit history is fine in this PR, because it mixes adding fuzzy testing and a fix found in one commit. It might be fine, but I want to have another opinion on that.

[Kidswiss]

We're introducing a completely new testing paradigm here. I'm not convinced if the additional complexity outweighs the benefits.

As for the found issue: Restic's ID's are well defined SHA-256 hashes. So if Restic ever returns something shorter than 8 characters, something is really, really wrong. IMHO I'd rather have the runner pod crash and burn instead of silently discarding it. At least then it should pop up in the backup monitoring.