SFT-7485: bind the UR path sequence to the part it carries

[Jacksper13]

A multipart UR carries its sequence number and count twice — once in the URI path, once inside the CBOR part. Decoder::receive() parsed both and compared neither, then sized and stored from the inner pair.

The encoder always writes the two from the same values: UR::MultiPartDeserialized's Display renders the path straight out of fragment.sequence / fragment.sequence_count. So they agree for anything this library produced, and a disagreement means the path is describing something other than what it carries.

receive() now binds them before the fountain sees the part:

let outer = match (ur.sequence(), ur.sequence_count()) {
    (Some(sequence), Some(sequence_count)) => (sequence, sequence_count),
    _ => return Err(Error::NotMultiPart),
};
let inner = (part.sequence, part.sequence_count);

if outer != inner {
    return Err(Error::InconsistentSequence { outer, inner });
}

The check sits after the part is decoded — it has to be, the inner values are in the CBOR — but before self.fountain.receive(), which is what allocates and mutates decoder state. Error::InconsistentSequence carries both pairs, so a caller can say what it saw.

The _ => arm is unreachable: is_multi_part() is checked at the top of receive(). It refuses rather than unwrapping, so the function has no panic of its own.

Not in this change

The ticket also asks for caller-configurable maxima on message bytes, fragments, equation rows and queued parts, and for heapless capacity failures to become structured errors throughout. Those add public API and want their own review; this is the binding that stops path metadata and part contents disagreeing in the first place. Worth saying that the binding removes the route the ticket describes for reaching those limits with hidden values, but it does not itself impose a ceiling on an honestly-declared large message.

Tests

In ur/src/ur/decoder.rs, each building its input by rewriting the path segment of a real encoder's output:

• two different parts of a multipart message, both wearing a 1-1 path — the case where a caller gating on the path sees two copies of one single part, and the two previously assembled into a message
• a part whose inner sequence is past its own count, behind a 1-1 path
• a correct sequence number with a wrong count
• an untouched stream, through the same to_string() / parse() path, still decodes to the original message

The first three fail without the check.

SFT-7485