Corpus shouldn't know about schedule bytes

[twof]

Problem

CorpusEntry carries a scheduleBytes: [UInt8]? field (and Corpus.add* / addIfInteresting thread it through their signatures). Schedule bytes are a concurrency-fuzzing-specific concept — they control task interleaving order and are only non-nil when schedule fuzzing is enabled. The signal-agnostic core (FuzzCore) should not bake in this particular feedback/fuzzing mode, exactly as it no longer bakes in coverage after the FuzzCore split.

It's also redundant and already half-removed from the data model:

• When schedule fuzzing is on, the schedule bytes are input element 0 of the flattened pack ([UInt8], repeat each Input) — i.e. they're already a normal input element.
• The scheduleBytes field is not persisted: CorpusEntry.encode(to:) writes only the input pack, and init(from:) sets scheduleBytes = nil. It's repopulated after load by peelScheduleResult from element 0.
• So today the field is a "user-facing convenience" duplicate of data that already lives in the input pack. Storing it on every entry is dead weight on the non-schedule-fuzzing path and a leak of a specific mode into the generic corpus.

See the comments already acknowledging this tension in Sources/FuzzCore/Fuzzing/Corpus/CorpusEntry.swift (lines ~23-25, 51-76).

Proposed direction

Remove scheduleBytes from CorpusEntry / Corpus and keep schedule bytes purely as input element 0 of the flattened pack (which is already the source of truth for persistence). Anything user-facing that wants "the schedule bytes for this entry" derives them from element 0 via the existing peelScheduleResult path, in the batteries/schedule-fuzzing layer — not in the core corpus type.

This mirrors the coverage decoupling from the signal-agnostic refactor (PR #43): the corpus becomes a plain input store and stops naming any specific fuzzing mode.

Affected code

• Sources/FuzzCore/Fuzzing/Corpus/CorpusEntry.swift — the field + init.
• Sources/FuzzCore/Fuzzing/Corpus/Corpus.swift — add / addIfInteresting / mergeCoverageAndAdd scheduleBytes: params.
• Call sites in FuzzStateMachine, FuzzEngine, CorpusCoordinator, FuzzPluginHandler, ScheduleFlatten (peelScheduleResult).

Notes / open questions

• Confirm nothing reads entry.scheduleBytes expecting it to be populated after a reload (it's nil post-decode today, so any such reader is already getting nil).
• Decide where the user-facing "schedule bytes for this entry" accessor lives once it's out of the core type (likely the schedule-fuzzing layer in PropertyTestingKit, alongside peelScheduleResult).