[Medium]: Centralize Graph query layer and improve fetch resilience

Nobody has claimed this yet.

### Problem Statement

Graph query setup and fetch handling are scattered. This should be centralized and made more reliable.

### Proposed Approach

Move Graph URL/query/request logic into shared graphql layer.
Replace inline usage in app with shared functions.
Add clear loading and error handling.
Add retry behavior where appropriate.
Remove placeholder token text from app logic.
Verify data flow remains correct.

### Files and Scope

event-dappp/src/App.js
event-dappp/src/graphql/queries.js

### Acceptance Criteria

- [ ] Graph fetch config is centralized in graphql layer
- [ ] App uses shared query helper instead of duplicated setup
- [ ] User-friendly loading and error states are shown
- [ ] Retry behavior is present and working

### Test Plan

Run app and confirm events and tickets load.
Simulate API/network failure and verify clean error state.
Retry fetch and verify recovery.

### Risks and Edge Cases

Query response shape mismatch can break rendering.
Retry settings may cause unnecessary repeated calls if misconfigured.

Start by comparing the Graph query and fetch setup in event-dappp/src/App.js with event-dappp/src/graphql/queries.js. Move the shared configuration and request behavior into the graphql layer, then run the app and simulate API or network failure. Done means events and tickets load through the shared helper, loading and error states are user-friendly, and retry recovers without unnecessary repeated calls.

Written by the indexing model from the issue text.