[client] Bound what one peer can announce to the file drop receiver

validateOffer bounded the file count and inline text but only checked the
sign of an announced size, and nothing limited the aggregate or how many
offers a sender could keep open. Every announced byte is staged in the spool
before delivery, so a peer decided how much of the receiver's disk to take:
512 files of 8 GiB were accepted unchallenged, and a flood of offers each
raised its own consent prompt.

Sizes are now capped per file and per offer, and a sender is held to a fixed
number of open offers. The aggregate accumulates against the remaining
headroom instead of summing first, because 512 files of 2^60 wrap an int64
back through zero and a plain sum would report such an offer as nil bytes.

The count is of open offers, not lifetime ones, so settling one frees a slot.

client/internal/filedrop/protocol.go

@@ -26,6 +26,18 @@ const MaxOfferFiles = 512
 // MaxInlineTextSize bounds an inline text snippet, which is held in memory.
 const MaxInlineTextSize = 64 * 1024
 
+// MaxFileSize bounds one announced payload, and MaxOfferSize the whole offer.
+// Every announced byte is staged in the spool before it is delivered, so
+// without these one peer decides how much of the receiver's disk to consume.
+const (
+	MaxFileSize  int64 = 100 << 30
+	MaxOfferSize int64 = 200 << 30
+)
+
+// MaxSenderOffers bounds how many offers one sender may have outstanding, so a
+// peer cannot flood the offer store or the consent prompts behind it.
+const MaxSenderOffers = 16
+
 const maxOfferBodySize = 1 << 20
 
 const (