Transaction confirmation and lifecycle tracking

Nessuno ha ancora preso questa issue.

## Summary

Implement transaction lifecycle tracking from broadcast through confirmation or rejection.

Parent: #4

## Flow

```
Broadcast (SYNC) → Mempool → Included in Block → Committed
│ │
▼ ▼
Evicted Rejected (execution error)
```

## Requirements

### Broadcast
- Use `BroadcastTxSync` (returns after mempool acceptance, not block inclusion)
- Capture tx hash from response
- Handle immediate rejection (invalid tx, mempool full)

### Confirmation polling
- Poll `TxStatus` at configurable interval (default: 1s)
- Timeout after configurable duration (default: 2 minutes)
- Return confirmed height and gas used on success

### Eviction handling
- If tx is evicted from mempool, optionally resubmit with same or bumped gas price
- Max resubmission attempts: configurable (default: 1)
- Log eviction events for debugging

### Rejection handling
- If tx is included but execution fails, capture error code, codespace, gas wanted/used
- Reset nonce to enable subsequent transactions (#8)
- Return structured error with all context

### Timeout handling
- If confirmation times out, return error but do NOT assume tx failed (it may still confirm)
- Track "unconfirmed" transactions for later reconciliation

## Interface

```go
type TxResult struct {
TxHash string
Height int64
GasUsed int64
Code uint32 // 0 = success
Error string // non-empty if Code != 0
Duration time.Duration // broadcast to confirmation
}

type TxTracker interface {
Submit(ctx context.Context, txBytes []byte) (*TxResult, error)
Pending() []string // tx hashes still awaiting confirmation
}
```

## References

- celestia-app `pkg/user/tx_client.go` — `ConfirmTx()`, eviction handling
- CometBFT `TxStatus` endpoint

Inizia leggendo pkg/user/tx_client.go di celestia-app, in particolare ConfirmTx() e la relativa gestione dell'eviction, quindi esamina l'endpoint TxStatus di CometBFT. Implementa il ciclo di vita specificato di TxTracker, includendo polling, nuova sottomissione, errori strutturati e hash in sospeso. Il lavoro è completato quando i comportamenti di conferma, rifiuto, eviction e timeout sono rappresentati da TxResult e Pending().

Scritto dal modello di indicizzazione a partire dal testo della issue.