Replace Scratchpad with something simplier and not dependent on SelfSerializable

[abies]

Scratchpad is a super complicated class, which is used only to store a single long value between the runs and is dependent on SelfSerializable, which we want to get rid of. Some simplier approach should be designed.

• We can keep most of the logic, but use PBJ wrappers instead of SelfSerializable
• We can get rid of entire generic Scratchpad class and just preserve that single ISS long as special case somewhere else

To be discussed.

[abies]

ISS Scratchpad — two options

Context

Scratchpad (platform-sdk/consensus-utility/.../scratchpad/) is a small
crash-safe key/value store whose only instance in the codebase is
platform.iss, currently holding a single field IssScratchpad.LAST_ISS_ROUND. It is
written by DefaultIssHandler on SELF_ISS / CATASTROPHIC_ISS and read once
by IssDetectionModule at construction to derive ignorePreconsensusSignatures,
which suppresses re-detection of an already-known ISS during PCES replay. Values
are SelfSerializable, written through SerializableDataOutputStream.

Precondition for both options: the change is made while no node holds a
non-empty ISS scratchpad, so the on-disk contents can be assumed empty. No
backward compatibility with the existing file format is required, and no
migration is needed. Leftover scratchpad/ directories become inert and can be
removed by operators at any time.

---

Option 1 — Remove the ISS recovery mechanism

Recovery from an ISS is performed operationally, by copying a state from a
healthy node. The in-platform restart-and-replay path is never used, so the
persistence that exists only to support it is removed. An ISS is reported and
the node stops.

Resulting behaviour

• SELF_ISS / CATASTROPHIC_ISS still log, emit IssNotification, and drive
  the node to the terminal CATASTROPHIC_FAILURE status. Nothing is persisted.
• ignorePreconsensusSignatures is no longer derived from any stored round. It
  remains driven solely by the test-only pces.forceIgnorePcesSignatures flag,
  so DefaultIssDetector keeps its constructor parameter unchanged.
• A node restarted on the same state after an ISS re-detects it during PCES
  replay and returns to CATASTROPHIC_FAILURE. This is the intended outcome:
  the supported recovery is to bring the node up on a state copied from a
  healthy node, whose round is past the ISS round, so replay contains nothing
  that can re-trigger detection.

Changes

Delete:

• org.hiero.consensus.scratchpad package in consensus-utility
  (Scratchpad, ScratchpadType, internal/StandardScratchpad) and
  ScratchpadTests.
• exports org.hiero.consensus.scratchpad; from the consensus-utility
module-info.java.
• IssScratchpad in consensus-iss-detection.

Modify:

• DefaultIssHandler — drop the issScratchpad constructor parameter, the
  field, and updateIssRoundInScratchpad(...); selfIssObserved and
  catastrophicIssObserver lose their call to it.
• IssDetectionModule — drop scratchpad creation, logContents(), the
  issRound read, and the initialStateRound/fileSystemManager constructor
  parameters if they become unused.
• ConsensusLayerFactory#createIssDetectionModule — drop the corresponding
  arguments.
• IssHandlerTests and any other test constructing the handler or module.
• Docs: docs/consensus-layer/architecture/topics/iss-detection.md (scratchpad
  section and the suppression bullets) and the matching delta map.

Notes

• Removes one of the remaining consumers of SelfSerializable /
  SerializableLong outside the event stream. Once the event stream is gone,
  the SelfSerializable machinery (ConstructableRegistry, class IDs,
  SerializableData*Stream) can be retired.
• The FUTURE WORK note in IssScratchpad about detecting repeated restarts
  from the same snapshot is dropped along with it; it was never implemented.

---

Option 2 — Keep Scratchpad, store PBJ objects instead of SelfSerializable

The scratchpad, its directory layout and its atomic-write semantics are kept;
the serialization moves from SelfSerializable to PBJ-generated messages, and
the SelfSerializable stack is dropped from the package entirely.

API

The V extends SelfSerializable bound on get / set / atomicOperation is
replaced by a PBJ record type. The reader needs a Codec for each value, and
the field enum already pins one message type per field, so the codec is supplied
by the field itself:

public interface ScratchpadType {
    int getFieldId();
    Codec<?> getCodec();
}

StandardScratchpad already builds a fieldId -> field map at construction; it
picks the codec from the field when reading and from the key when writing. No
type discriminator is written to the file, and no reflection is involved.

The consequence is that a field's message type is fixed by the enum. Evolving a
value means evolving its proto message under the usual protobuf compatibility
rules, not swapping in a different type.

File format

The whole file becomes a single PBJ message, so the hand-rolled framing and the
SelfSerializable stack disappear together. Add to
hapi/hedera-protobuf-java-api/src/main/proto/platform/state/scratchpad.proto
(package com.hedera.hapi.platform.state):

message ScratchpadFile {
    uint32 version = 1;
    repeated ScratchpadEntry entries = 2;
}

message ScratchpadEntry {
    uint32 field_id = 1;
    bytes  value    = 2;   // the field's own message, encoded with its codec
}

Values stay opaque bytes at the envelope level; each is encoded and decoded
with the codec its field supplies. version is set to 2 and validated on
read — protobuf gives field-level evolution for free, so the version exists only
to reject a stale v1 file rather than to gate a reader.

StandardScratchpad then does its IO entirely through PBJ:

• write: build the ScratchpadFile, one entry per non-null field with
  value = codec.toBytes(record), then
  ScratchpadFile.PROTOBUF.write(file, new WritableStreamingData(out)) over the
  existing buffered FileOutputStream;
• read: ScratchpadFile.PROTOBUF.parse(new ReadableStreamingData(in)), then for
  each entry resolve the field from field_id and parse
  entry.value().toReadableSequentialData() with that field's codec.

Everything else about the class is untouched: directory layout, the
0.scratchpad, 1.scratchpad rotation, temp-file-plus-ATOMIC_MOVE, and the
delete-all-but-newest recovery on load.

Removing the SelfSerializable dependency

With the above, nothing in the scratchpad package touches the legacy stack:

• drop SerializableDataInputStream / SerializableDataOutputStream from
  StandardScratchpad in favour of ReadableStreamingData /
  WritableStreamingData;
• drop the SelfSerializable bound on Scratchpad#get / #set /
  #atomicOperation and on the data map, leaving a plain type variable — the
  value type is already pinned per field by the enum;
• drop the org.hiero.base.io imports from the package; consensus-utility
  already requires transitive com.hedera.pbj.runtime, so no module-info change
  is needed;
• no ConstructableRegistry entry is needed for the new value types, since
  codecs are resolved from the enum rather than from a class ID on disk.

This removes the scratchpad as a consumer of SelfSerializable. Once the event
stream is gone, the remaining machinery (ConstructableRegistry, class IDs,
SerializableData*Stream) can be retired.

Changes

• Scratchpad, ScratchpadType, StandardScratchpad — codec accessor on the
  field enum, generic bound, loadFromDisk / flushToTemporaryFile rewritten
  against the envelope message, version bump. logContents() is unaffected:
  PBJ records have a generated toString().
• New scratchpad.proto with ScratchpadFile / ScratchpadEntry, plus a
  message for the ISS value itself, since codecs are per-message and there is no
  suitable existing one for a bare round number — e.g.
  IssScratchpadData { uint64 last_iss_round = 1; } — wired to
  IssScratchpad.LAST_ISS_ROUND.
• DefaultIssHandler#updateIssRoundInScratchpad and IssDetectionModule's read
  switch from SerializableLong to the new message.
• ScratchpadTests and IssHandlerTests.

Variation — drop the field enum, make the file a typed message

Instead of a generic envelope keyed by field_id, each scratchpad is one
concrete proto message with named, typed fields. For ISS that is the whole
schema:

message IssScratchpad {
    // absent when this node has never observed an ISS
    optional uint64 last_iss_round = 1;
}

ScratchpadType, the IssScratchpad enum, ScratchpadFile and
ScratchpadEntry all disappear, together with the fieldId -> field map, the
EnumSet of fields, the duplicate-field-id check and the unknown-field-id error
path. Scratchpad loses its key parameter and is generic only over the message:

public interface Scratchpad<T> {
    static <T> Scratchpad<T> create(
            FileSystemManager fsm, NodeId selfId, Codec<T> codec, String id);

    @Nullable T get();
    void set(@Nullable T value);
    void update(UnaryOperator<T> operation);   // atomic read-modify-write
}

Construction becomes
Scratchpad.create(fileSystemManager, selfId, IssScratchpad.PROTOBUF, "platform.iss"),
and updateIssRoundInScratchpad becomes an update that returns a rebuilt
record via the generated builder when the observed round is higher. No
version field is needed: protobuf covers evolution, and a stale v1 file fails
to parse.

Presence. Proto3 scalars cannot distinguish unset from zero, and the ISS
logic depends on that distinction — null means "never observed", while round
0 is genesis. optional uint64 (explicit presence) is therefore required
here, and for any future field whose absent state is meaningful.

Tradeoff — no single-field store. Every mutation rewrites and re-encodes
the entire message. The current implementation already does this: flush()
serializes all fields and rewrites the file on each set, so there is no
regression today at one field. What is given up is the option of ever adding
per-field or append-only writes without going back to a keyed format. That
matters only if a scratchpad later holds large values or independent
high-frequency writers; for the ISS round it does not.

What is gained. No envelope and no double encode/parse of value bytes — one
message written and one parsed, rather than the envelope plus N nested payloads.
Access is statically typed instead of an unchecked cast, field numbers replace
the hand-managed getFieldId(), and logContents() is just toString() on the
message.

Delta against the sections above. No scratchpad.proto envelope, only the
per-scratchpad message; ScratchpadType and the IssScratchpad enum are
deleted rather than modified; Scratchpad and StandardScratchpad lose the K
type parameter along with the data map, holding a single value instead.

[abies]

We think we should not remove it. While it is unlikely we will ever use auto-recovery in production, the scratchpad is also used during a manual restart after an ISS. If the ISS was caused by some flaky behavior, simply restarting the node could be sufficient to fix it. Thus, Option 2 it is.