Markets shown to users are hardcoded fixtures, not contract state

[Muyideen-js]

Problem

The markets a visitor sees are invented in JavaScript and have no relationship to the deployed
contract.

• frontend/pages.js:1 -- pageMarkets is a literal array of six markets with hardcoded yes:
  percentages (54, 68, 76, 47, 61, 43) and close labels like "Month end"
• frontend/script.js:9 -- baseMarkets is another hardcoded array; exactly one entry carries
  onchainId: 3, and only that one can be traded

The probability bars are therefore decoration. A market shown at "68% Yes" is 68% because someone
typed 68, not because of anything in the YES/NO pools. The catalogue does not change when markets
are created, resolved, or cancelled on chain.

The contract already exposes everything needed: get_market_count, get_market(market_id),
get_open_market_count, get_market_bettors_page.

Acceptance criteria

• markets.html and the landing page enumerate real markets via get_market_count +
  get_market, with no hardcoded market array left in the codebase
• Implied probability is derived from the YES/NO pool totals, not a literal
• Close time, resolution status, and cancellation state come from the contract
• Resolved and cancelled markets are visibly distinguished from open ones
• Read calls use simulation only -- no signing, no fees (see the read-only pattern in
  docs/CONTRACT_CALLS.md)
• Empty state when no markets exist; error state when RPC is unreachable

Why this is critical

The product presents itself as a live prediction market. Today it displays fiction with a real
Connect button next to it, which misleads anyone who funds a wallet and tries to trade.

[Okorie2000-code]

Hi Maintainer, I’ve reviewed the issue and I’m confident I can deliver a solid solution. Kindly assign it to me.

[rupesh-kumar-sah]

Hello! I'd like to work on this issue.

I would like to resolve this issue. Here is my proposed execution plan:

• Implementation: Implement Markets shown to users are hardcoded fixtures, not contract state with explicit require_auth checks, clean storage layouts, and robust Soroban contract logic.
• Testing: Add comprehensive unit tests verifying both happy-path invocations and unauthorized revert scenarios.

Happy to pick this up today—please assign to me!

[shobhamerabacha-star]

Hey team,

I would like to resolve this issue. Here is my proposed execution plan:

• Implementation: Implement Markets shown to users are hardcoded fixtures, not contract state with explicit require_auth checks, clean storage layouts, and robust Soroban contract logic.
• Testing: Add comprehensive unit tests verifying both happy-path invocations and unauthorized revert scenarios.

Excited to work on this—please assign to me and I'll submit a clean PR shortly!