fix(handlers): harden gacha_items and boost time limit ACK paths

Both bugs surfaced when running protbot against a live Erupe instance.

LoadColumnWithDefault now treats an empty bytea ('\x', len 0) the same
as NULL. The postgres driver returns a non-nil empty slice for empty
bytea, so the prior `data == nil` check let a zero-byte slice reach
handleMsgMhfReceiveGachaItem, which forwarded it to the client as a
malformed gacha_items response. The MHF client interprets a zero-byte
count field as a protocol error and crashes the gacha menu, matching
the #175 symptom class. The handler also gains a defensive fallback
for len(data) == 0 in case another caller hits the same edge.

handleMsgMhfGetBoostTimeLimit was sending two ACKs for a single
request: doAckBufSucceed with the real payload, then an unconditional
doAckSimpleSucceed on the same ack handle. The second ACK was dead on
arrival (the handle was already consumed) but is a latent protocol
bug. Drop it and update the regression test that was asserting the
buggy 2-packet behavior.

server/channelserver/handlers_cafe_test.go

@@ -231,7 +231,9 @@ func TestHandleMsgMhfGetBoostTimeLimit(t *testing.T) {
 
 	handleMsgMhfGetBoostTimeLimit(session, pkt)
 
-	// This handler sends two responses (doAckBufSucceed + doAckSimpleSucceed)
+	// One response: the stray second ACK (doAckSimpleSucceed) was removed
+	// because it fired with the same ack handle as the real buf ACK, which
+	// is a protocol bug.
 	count := 0
 	for {
 		select {
@@ -242,8 +244,8 @@ func TestHandleMsgMhfGetBoostTimeLimit(t *testing.T) {
 		}
 	}
 done:
-	if count != 2 {
-		t.Errorf("Expected 2 response packets, got %d", count)
+	if count != 1 {
+		t.Errorf("Expected 1 response packet, got %d", count)
 	}
 }