Bug: Incorrect PID and multiprocess mode parsing in RedisMultiProcessCollector

## Problem

In `src/gunicorn_prometheus_exporter/storage/redis_backend/storage_collector.py`, the `_add_sample_to_metric` method incorrectly parses Redis keys for gauge metrics, leading to wrong PID extraction and multiprocess mode detection.

## Current Code (Lines 172-186)

The current implementation extracts:
- PID from the **last** key segment (`key_parts[-1]`)
- Multiprocess mode from the **third** key segment (`key_parts[2]`)

## Expected Key Structure

Redis keys follow the pattern: `gunicorn:gauge_min:12345:metric:hash`
- Index 0: prefix ("gunicorn")
- Index 1: type with mode ("gauge_min", "gauge_max", "gauge_all", etc.)
- Index 2: PID ("12345")
- Index 3: "metric"
- Index 4: hash

## Impact

This bug causes:
1. **Incorrect PID labeling**: Process identification fails for gauge metrics
2. **Wrong multiprocess mode**: Aggregation semantics are broken (min/max/sum/mostrecent modes)
3. **Cleanup issues**: Dead process cleanup may not work properly
4. **Prometheus compatibility**: Violates expected multiprocess gauge behavior

## Suggested Fix

```python
# Extract PID from index 2, not the last segment
pid = key_parts[2] if len(key_parts) > 2 else "unknown"

# Extract mode from index 1 (gauge_min -> min)
file_prefix = key_parts[1] if len(key_parts) > 1 else ""
metric._multiprocess_mode = file_prefix.split("_", 1)[1] if "_" in file_prefix else "all"
```

## File Location

`src/gunicorn_prometheus_exporter/storage/redis_backend/storage_collector.py` around lines 172-186

## Priority

**High** - This affects core multiprocess gauge functionality and Prometheus compatibility.

## Referenced From

Pull Request #82, comment: https://github.com/Agent-Hellboy/gunicorn-prometheus-exporter/pull/82#discussion_r2350338358