graphdb: fix backwards-compat for channel edge feature deserialization

This commit fixes a backwards compatibility issue that prevented nodes
from upgrading from v0.19.x to v0.20.x.

In v0.19.x, channel edge features were serialized as raw feature bytes
without a length prefix. In v0.20.x (commit 2f2845dfc), the serialization
changed to use Features.Encode() which adds a 2-byte big-endian length
prefix before the feature bits. The deserialization code was updated to
use Features.Decode() which expects this length prefix.

When v0.20.x reads a database created by v0.19.x, Decode() tries to read
a length prefix that doesn't exist, causing an EOF error:

    unable to decode features: EOF

The fix adds a deserializeChanEdgeFeatures() helper that detects which
format is being read and decodes accordingly:

- New format (v0.20+): First 2 bytes encode the length of the remaining
  bytes. Detected when uint16(bytes[0:2]) == len(bytes)-2.

- Legacy format (pre-v0.20): Raw feature bits without length prefix.
  Uses DecodeBase256 with the known length.

The format detection is safe because in the legacy format, the first byte
always has at least one bit set (the serialization uses minimum bytes),
so the first two bytes can never encode a value equal to len-2.

Fixes #10528.

docs/release-notes/release-notes-0.20.1.md

@@ -62,6 +62,13 @@
   due to validation checks in the graph Builder that were resurfaced after the
   graph refactor work.
 
+* [Fix backwards compatibility for channel edge feature
+  deserialization](https://github.com/lightningnetwork/lnd/pull/10529). Nodes
+  upgrading from pre-v0.20 versions could fail to read channel edges from their
+  graph database due to a format change in how channel features are serialized.
+  The fix adds automatic format detection to handle both legacy (raw feature
+  bits) and new (length-prefixed) formats.
+
 # New Features
 
 ## Functional Enhancements