Test against real Lambda Feedback exports

[peterbjohnson]

in2lambda writes files for Lambda Feedback to import, but nothing checks its output against what Lambda Feedback actually produces. We have a real exported question set, and we will accumulate many more; adding one to the test data should never require changing code.

Done when a real export is part of the test data, the suite loads it, writes it back and compares, and dropping another export beside it is picked up on its own. The filter tests need the same treatment: they name each filter by hand, so a new filter is covered only if someone remembers.

The first real export is already on main in tests/fixtures/exports/, with a README describing the export's JSON. Those files are exactly as Lambda Feedback wrote them and must stay that way.

---

Workbench ticket t19.

[m-messer]

The filter refactor is a great change.

Testing an exported version of a set from LF is a great idea, but I think it is the wrong implementation. If the LF import schema changes, the test code won't detect it, and all test documents will become stale and need to be regenerated. A more complex but more robust approach would be to provide a file to in2lambda, send it to staging or some specific test environment, and then export the set to validate the entire end-to-end pipeline.