## Purpose

Getting guests into the system and keeping them correct: manual add/edit, bulk CSV import with mapping and per-row validation, event tagging, deduplication, and soft delete.

## ADDED Requirements

### Requirement: Addressable guest list filters (P1)
The guest-management screen SHALL accept its event selection from the address it was opened
at, so another screen can link to one event's guest list. The screen's filter state SHALL be
reflected in the address as the admin changes it, so the view can be shared, bookmarked, and
returned to with the browser's back button.

#### Scenario: Arriving with an event pre-selected
- **WHEN** the guest screen is opened at an address naming a specific event
- **THEN** the list shows only that event's guests and the event filter control shows that event as selected

#### Scenario: Arriving with no event named
- **WHEN** the guest screen is opened with no event in the address
- **THEN** it behaves as it does today, listing guest records across all events

#### Scenario: Changing a filter
- **WHEN** an admin changes the event, status, side, tag or search filter on the screen
- **THEN** the address updates to describe the resulting view, without adding a history entry per keystroke

#### Scenario: Going back
- **WHEN** an admin narrows to one event and then presses the browser's back button
- **THEN** they return to the view they came from rather than leaving the screen

#### Scenario: Unknown or malformed event
- **WHEN** the address names an event that does not exist or is not a valid identifier
- **THEN** the screen loads without crashing, reports that the event could not be applied, and falls back to the unfiltered list

#### Scenario: Counts stay honest
- **WHEN** an event filter is active
- **THEN** the total is described as a count of guests; with no event filter it remains a count of guest records, because a person attending three events is three records