Athanasius

*If* there's been a `NavRouteClear` by the time we try (again) to read the `NavRoute.json` file then we don't fall over, but we will push a UI error/badsound about there...

In thinking about "what happens if a single EDDN message is rejected?" for other work I've come to the conclusion that what we should do is just use an sqlite...

NB: The OP comment is in error. The current replaylog *does* store which Commander the message was for/from. Still, it might be worth looking into changing this from a flat...

As part of this we can also make this work more like the Inara API code in its plugin, but instead of a straight up timer we pay attention to...

Only possibly via using the CAPI as the source of the data when we see an 'undock' event in the journal. I forget if the CAPI updates to not have...

See also #462

Having worked with the CAPI data whilst working on another issue I now know that the moment you undock you *do* still have CAPI lastStarPort data available, and will continue...

This will have to be dependent on https://github.com/EDCD/EDMarketConnector/projects/10 because we can't go just blindly adding a desktop shortcut, there **will** be users upset at us messing up their nice clean...

Thanks to #1240 we now use `logger.trace_if('', '')` which will make these easier to find. However a simple grep might not work for, e.g.: ```python logger.trace_if( 'wibble', f'Some overly long...

- [ ] We already moved to a queue system for CAPI requests, so no chance of parallel requests. **But we might want to add a check for "query to...