bug

The error comes from `offer_for_bid()` in `swap.py` (and a twin check in `make_offer`). It fires when this wallet's offer book already holds an open offer, or a sent-but-unconfirmed sale, for the same inscription. I'll look at what's in the book now, along with the offers page and the code around it.

The seller wallet already accepted an offer on inscription #58 five minutes ago (open, expiring in ~10 min, with a coin locked and acceptance message sent) — so any second accept will hit that same open offer. I also noticed swap.py has changed since I last read it, so I'll check the offers page, buyer-side bid records, the current offer_for_bid code, file modification times, and on-chain/node status to confirm what's happening.

The Exchange page still shows an active Accept button for @gx10's offer even though this wallet accepted it 5 minutes ago, likely due to today's server update. I'll check how the new code handles accepted offers, whether there's a pending state on the page, and whether @gx10's wallet has responded yet.

My Accept has 8 confirmations and is locked in, but @gx10's wallet hasn't responded and the offer expires in ~8 minutes—likely because `shopkeeper._bid` needs a bid row it writes itself, which I haven't found yet. I'll check for a raw-SQL insert and review the updated "Make offer" route before confirming.

The code confirms `add_bid()` is never invoked, and the "Make offer" route doesn't record a bid either. Next, I'll check the exact expiration time of the reservation and whether @gx10 has replied recently.

You already accepted this offer, and the second Accept ran into your own first one. The "somebody else" is actually the same buyer, @gx10.

## What happened
- Your first Accept on #58 (Goofball #63, 25,000 coins from @gx10) worked. It reserved the NFT for 15 minutes, locked coin `86fb4afb…:0`, and sent @gx10 the acceptance (message `f30c3cec…`, now 8 confirmations).
- The Exchange page doesn't show that anything happened. It draws an Accept button for every on-chain offer and never checks what you've already accepted ([exchange.html:82](C:/Users/danie/.dogecoinarcade/src/arcade/web/templates/exchange.html:82)).
- Clicking again hits the check at [swap.py:685](C:/Users/danie/.dogecoinarcade/src/arcade/swap.py:685). It refuses any second offer on an item that already has an open one, even when it's the same buyer and the same price. That's why the message is misleading.

The reservation expires at **3:49:47 PM**, and Accept will work again after that.

## Why @gx10 hasn't signed
This is the bigger problem, and a second Accept will probably time out the same way. @gx10's wallet only signs an acceptance if it finds a matching "bid" row it wrote when it made the offer ([shopkeeper.py:188](C:/Users/danie/.dogecoinarcade/src/arcade/shopkeeper.py:188)). Nothing in the code ever writes that row:
- `add_bid()` ([swap.py:425](C:/Users/danie/.dogecoinarcade/src/arcade/swap.py:425)) is never called.
- The Make offer route ([app.py:4303](C:/Users/danie/.dogecoinarcade/src/arcade/web/app.py:4303)) broadcasts the offer and records nothing.

So @gx10's wallet silently ignores your acceptance and the reservation runs out. @gx10 runs a different build (`54556f5`) that I can't see. But 8 blocks with no reply, and nothing at all in your inbox, fits this.

Even with that fixed, the trade would then hit yesterday's "input 1 is spent or unknown" bug. @gx10's wallet would pay for its reply with the same coin its swap half uses.

## Fixes
1. **Buyer side:** write a bid row when making an offer. Or have `_bid` check the chain's offer table for an offer from one of its own addresses, instead of the bid table.
2. **Seller side:** if the same buyer's offer is already accepted, say "accepted, waiting for @gx10, expires 3:49 PM" instead of this error. Show that on the Exchange page in place of the Accept button.
3. **Yesterday's bug:** stop the reply message from spending the swap's own coin, in both