Refactor WeightScreen: improve API handling, validation, and state management

## Summary
The current implementation of `WeightScreen` works functionally but contains multiple structural, reliability, and maintainability issues. These need to be addressed to align the component with production-grade standards and improve long-term scalability.

---

## Areas of Concern

### **1. API Handling (High Priority)**
Currently, all network requests are made using raw `fetch` inside the component:

- `GET /weight`
- `POST /weight`
- `PUT /weight/:id`
- `DELETE /weight/:id`

**Problems:**
- Repeated boilerplate code
- Inconsistent error handling
- No timeout handling
- No retry mechanism
- Harder debugging and maintenance

**Proposed Fix:**
Introduce a centralized API client (e.g., `apiClient.js`) and replace all direct `fetch` calls.

---

### **2. Missing Loading State (UX Issue)**
There is no loading indicator when fetching weight history. If the API is slow, the user sees a blank screen with no feedback.

**Expected Behavior:**
A loader or skeleton should appear while data is being fetched.

---

### **3. Unsafe Date Handling**
The function `formatLocalDate` manually appends `"Z"` to timestamps:

```js
const dateStringWithZ = utcDateString.endsWith('Z')
? utcDateString
: `${utcDateString}Z`;
````

This:

* Assumes backend always returns UTC
* May cause incorrect timestamps
* Can break if backend format changes

**Proposed Fix:**
Use a proper date library like `dayjs` or `date-fns`, or rely strictly on backend ISO format.

---

### **4. Insufficient Input Validation**

Current validation only checks for empty fields:

```js
if (!week || !weight) return;
```

It does NOT prevent:

* Negative weeks
* Week > 40
* Negative or zero weight
* Non-numeric values

**Expected Validation:**

```js
const weekNum = parseInt(week);
const weightNum = parseFloat(weight);

if (weekNum < 1 || weekNum > 40) {
Alert.alert("Invalid week");
return;
}
if (weightNum <= 0) {
Alert.alert("Invalid weight");
return;
}
```

---

### **5. Unstable Keys in List Rendering**

The history list currently uses index as key:

```js
{history.map((entry, index) => (

```

This can cause incorrect UI behavior when items are edited or deleted.

**Fix:**
Use a stable unique key:

```js

```

---

### **6. State Mutation with reverse()**

This line mutates the original array:

```js
setHistory(data.reverse());
```

**Fix:**

```js
setHistory([...data].reverse());
```

---

### **7. Potential Crash in Edit Flow**

If `editData` is accessed before being set, it could cause runtime errors.

**Safer initialization:**

```js
const [editData, setEditData] = useState({
id: null,
week_number: '',
weight: '',
note: ''
});
```

---

### **8. No Optimistic UI Updates**

After every create, update, or delete, the screen refetches the entire list instead of updating local state first. This makes the UI feel slower.

**Expected Improvement:**
Update UI optimistically, then sync with server.