Mapper QA user story

One of the main purposes of Speedwalk is to find problematic data and inconsistent tagging somewhere, and make it easy for somebody to manually fix these issues. A few fixes are possible in Speedwalk directly, but many will just be opening another editor in a targeted area and having a clear task. Speedwalk's job is more to detect these problems and make the overall workflow of tackling them easy.

When all of the problems somewhere are resolved, then automated processing -- generating separate sidewalks where they're missing, and generating all possible crossings (as desire lines, even when nothing really exists) should yield pretty clean results.

## Workflow

We need to figure out the overall workflow for this. Some known tasks:

- [ ] Open iD using `gpx=` or Rapid using `wktPoly=` to focus on an area
- [x] Make it easier to refresh and grab latest OSM data after doing some work in another editor
- [x] Present a very clear task list of problems to solve, making a sense of progress more clear

## The QA checks

- There are already some "problems" defined in the tool, with some pending ones as other GH issues
- We need to think through ways of ignoring false positives (persisting those how?)
- There are some new ideas around sidewalk consistency. https://www.openstreetmap.org/way/311651687#map=18/52.757318/13.240729 is a good example of two problems. A separate sidewalk is mapped only one side, with the other tagged as `yes`. And the separate sidewalk covers almost all of this road, except a few blocks. We should urge mappers to manually finish the separate sidewalks here. It's better to consistently map separate sidewalks for an entire section of road, rather than disconnected stops and starts.
- We need a new crossing audit mode; I'll start another issue to think through this more

The issue describes a high-level workflow for QA and problem detection in sidewalk mapping. It references existing 'problems' in the tool and ideas for new checks like a crossing audit mode. Start by exploring the codebase for existing problem definitions and UI components that present tasks. Understanding how the tool currently opens external editors (iD/Rapid) and refreshes OSM data is key. 'Done' means designing and implementing a clear task list UI and workflow, not just a single code change.

Written by the indexing model from the issue text.