fix: handle malformed configuration payloads without panics

[anyasabo]

Problem

PR #465 changed the legacy v1 decodePeers path to return errors instead of panicking on malformed input. The v2+ DecodeConfiguration call sites still panicked on malformed bytes in key runtime paths.

For a core distributed-systems library, panicking on malformed persisted or remote payloads is an availability risk. These paths should reject bad payloads and keep the process alive.

What changed

• Added internal decodeConfiguration([]byte) (Configuration, error) as an error-returning counterpart to DecodeConfiguration.
• Updated appendEntries config-entry handling (processConfigurationLogEntry, LogConfiguration case) to return errors instead of panicking.
• Updated installSnapshot (SnapshotVersion > 0) to return RPC errors on malformed configuration payloads instead of panicking.
• Updated runFSM / applySingle (ConfigurationStore path) to log decode failures and skip malformed LogConfiguration entries instead of panicking.
• Added/strengthened regression tests for malformed configuration payload handling and post-failure state invariants, including startup replay coverage.

Behavior and invariants

AppendEntries (LogConfiguration)

• Malformed config payload now returns an RPC error (AppendEntriesResponse.Success=false) instead of panicking.
• Entry may already be persisted in the log store (existing ordering), but:
  • lastLog is not advanced on decode failure,
  • configuration state is not mutated.

InstallSnapshot (SnapshotVersion > 0)

• Malformed snapshot configuration now returns an RPC error (InstallSnapshotResponse.Success=false) instead of panicking.
• Snapshot/configuration state remains unchanged on decode failure.

FSM apply (ConfigurationStore)

• Malformed committed LogConfiguration entries are logged and skipped (no panic).
• Subsequent valid configuration entries continue to apply.

Startup replay (NewRaft log scan)

• Replaying a persisted malformed LogConfiguration entry now returns a decode error instead of panicking while scanning configuration entries during startup.

Ordering note

For LogConfiguration, decode now happens before configuration-state mutation in processConfigurationLogEntry. This prevents partial state promotion when decode fails.

The deprecated peer-log branch (LogAddPeerDeprecated / LogRemovePeerDeprecated) is unchanged in this PR.

Scope / follow-up

This PR intentionally focuses on panic-to-error behavior in decode paths.

In the append path where StoreLogs succeeds and later config processing fails, behavior is now:

• before/after this PR: return an error with persisted entries, and lastLog cache may remain stale on that return path.

Keeping lastLog cache in sync in that failure path is tracked as a separate follow-up in PR #6.

Why this is safe

• Success-path behavior for valid payloads is preserved.
• Failure-path behavior changes from process crash to explicit error handling.
• Existing exported DecodeConfiguration panic semantics are preserved for callers that rely on panic-on-error behavior.

Test plan

• go test -run "TestRaft_(NewRaftMalformedConfigurationEntryInLogReturnsError|RunFSMMalformedConfigurationSkipsEntryAndContinues|AppendEntriesMalformedConfigurationReturnsError|InstallSnapshotMalformedConfigurationReturnsError)" -count=1 .
• go test -run "TestRaft_.*Configuration.*" -count=1 .