Build a small, functional equipment-rental browser app in a NEW frontend repository, using Vite, React and TypeScript. Deliver source, a lockfile, a static production build, setup instructions and automated tests. This is a public, disposable testnet demonstration with an existing contract deployment. It must perform real wallet interactions, not simulate successful payments.

Use these existing deployments, without changing or redeploying contracts:

• Robinhood Chain Testnet, chain ID 46630, native test ETH.
• Public RPC https://rpc.testnet.chain.robinhood.com
• Explorer https://explorer.testnet.chain.robinhood.com
• MockPaymentToken: 0x31339619db548257cE09A76f189b0b1932f5c0cd
• RentalEscrow: 0x06135FF9311eCa80a7484444A552f28fFC660F05
• Authoritative contract source: https://github.com/identity-md-launches/launch-1988-kkk at commit 6ce8023819f68d2b84f2151b24285af477f4d9c7. Inspect its Solidity and derive/check the full ABI against that exact commit; do not guess signatures.

The journey:

1. Display a clear TESTNET / mock tokens notice. Connect a browser wallet, including Rabby, with explicit user action. Show connected address, chain, token balance and available equipment. For this bounded demo focus on item 1, but read its actual existence, listing status, state and policy from the contract. Treat metadata as untrusted text, never executable HTML.
2. Show the current deposit, cancellation fee and reservation expiry rules before approval/booking. The existing policy is expected to be a 50-token deposit, 5-token cancellation fee and 24-hour reservation window, but on-chain reads must determine the displayed values. Read token decimals; the deployed token has 6. All monetary calculations must use integer base units, never floating-point arithmetic.
3. Read current ERC20 allowance on-chain, and request only the approval needed for this deposit, never an unlimited approval. Approval and reservation are separate wallet actions, with clear progress and receipt links. Explain that test ETH pays gas and mock tokens pay the deposit.
4. Reserve with reserve(itemId, expectedPolicyId, clientRef). Preserve the policy the user accepted. If the quote changes, stop and require renewed acceptance. Use a nonzero random clientRef and retain the pending operation, reference and any transaction hash across reloads, scoped by chain, escrow and wallet. Disable duplicate submissions while pending. Before retrying an uncertain reservation, resolve its receipt and reservationByRef; do not silently generate a new reference and pay again.
5. Display the resulting reservation ID, status, and accepted terms from getReservation, not from the item's current policy. Recover this booking after refresh. Also provide reservation-ID lookup with clear ownership information; do not claim local browser storage is complete account history.
6. Allow the renter to cancel a reservation only when its current on-chain state and expiry permit it. After confirmed cancellation, display refundCreditOf and offer a separate withdrawRefund action. Cancellation creates a credit; do not describe it as money already returned to the wallet. Read the current refund credit before withdrawal because it may include other reservations. Refresh balances, availability and reservation state after each confirmed action.

Handle disconnected wallets, wrong network, account/chain changes, insufficient balances, rejected signatures, reverted/replaced transactions, unavailable RPC and delayed receipts. Do not show success until a successful receipt is observed; make confirmation state explicit. Clear account-specific displayed state when the account changes. Revalidate chain, account, quote and applicable contract state before each write. An unavailable RPC must produce an honest error/retry state, never fake data or a false payment success.

Keep this task bounded:

• Frontend only. Read directly from the public chain and send writes through the user's wallet. There is no public backend URL for this task. Do not create a backend, indexer, database, authentication service or new contracts, and do not require access to any private repository or hosting account.
• No admin/staff operations, fee collection, token minting, real payments or production-network support in this version.
• No private keys, recovery phrases, server credentials or signing secrets. Workers must not transact against the live testnet contracts. Automated wallet/write tests must use mocks or an isolated local chain; public testnet reads are allowed.
• Public frontend configuration may contain only public network/contract information. Never put a secret in a VITE variable or bundle.

Provide meaningful automated tests for booking/cancel/refund state transitions, 6-decimal amounts, exact approvals, changed-policy acceptance, duplicate clicks, pending-operation recovery after reload, rejected/reverted transactions, wrong-chain/account changes and RPC failure. Include a reproducible browser smoke test with a mocked injected wallet and mocked RPC, covering the complete journey. Report commands and actual results, clearly distinguishing mocked/local tests from any live read-only checks.

Use a simple readable responsive interface with explicit loading/error/pending states. Include a README with exact install/build/test commands, static-hosting instructions, ABI provenance, limitations and a short manual Rabby acceptance checklist. Do not claim backend integration or production readiness.