Two improvements to create_time_agg_wp_agg_vismap_plot and create_aset_map_plot

## Context

We are using fdsvismap 0.1.3 to pre-compute visibility maps for a fire evacuation routing model (T-corridor scenario, 300 s FDS run, 3 waypoints). Two issues came up when interpreting the diagnostic plots.

---

## Issue 1 — Coverage map uses logical AND over all time steps (too strict)

### Current behaviour

`create_time_agg_wp_agg_vismap_plot` aggregates with:

```python
self.time_agg_wp_agg_vismap = np.logical_and.reduce(self.all_time_wp_agg_vismap_list)
```

A cell appears **green** only if it can see at least one waypoint at **every** time step. In any realistic fire scenario smoke eventually fills the domain, so virtually every cell ends up red — even cells that have clear sign visibility during the critical early evacuation window. The map becomes uninformative.

### Suggested fix

1. **Change to logical OR** (or make it configurable via a parameter): a cell is green if it can see any sign at *any* time step. This answers the practically useful question: *"does this agent position ever have sign coverage?"*
2. **Add a `t_max` parameter** to both the aggregation and the plot method, e.g.:
```python
create_time_agg_wp_agg_vismap_plot(t_max=120)
```
so users can restrict the aggregation to the evacuation-relevant window instead of the full simulation duration.

### Concrete example

300 s FDS run, smoke fills a T-corridor by t ≈ 60 s. With AND, the entire corridor is red at t > 60 s and the map shows almost nothing. With OR (or `t_max=60`), the map correctly shows which corridor zones had sign coverage during the window that matters for routing decisions.

---

## Issue 2 — ASET map has misleading blue spots at sign locations

### Current behaviour

`create_aset_map_plot` shows the time at which each cell first loses visibility to any sign. Cells immediately adjacent to a sign location always appear **blue** (latest visibility loss), even when those cells are in the densest smoke region (e.g., next to a fire source).

### Why it happens

A cell at distance ≈ 0 from a sign always satisfies the Beer-Lambert condition `c / K > distance`, so it never "loses" visibility regardless of local smoke density. This is geometrically correct but physically misleading: it suggests that the area right next to the sign has the best visibility, when in reality it may be the most dangerous location in the scenario.

### Suggested fix

Exclude cells within one grid cell of a waypoint position from the ASET colormap (or mark them with a distinct symbol/hatch), so the gradient in the surrounding area is not visually dominated by the proximity artifact. Alternatively, document this behaviour prominently in the docstring.