test(e2e): add multi-configuration emulator fixture

[groupsky]

Background

Currently, E2E tests for discover filters use the default test fixture which may have a single baud rate/parity configuration. To fully validate that filters correctly reduce the search space, we should test against devices with known configurations.

Proposal

Create a dedicated emulator fixture with multiple known configurations:

• Device 1: ID=1, 9600 baud, none parity
• Device 2: ID=2, 19200 baud, even parity
• Device 3: ID=3, 9600 baud, odd parity

This would allow E2E tests to verify:

• --baud-rate 9600 finds only devices 1 and 3
• --parity even finds only device 2
• --id 1-2 --baud-rate 9600 finds only device 1
• Combined filters correctly reduce combinations

Benefits

• More robust E2E validation
• Documents expected behavior
• Catches regressions in filter logic

Related

PR #332 - discover command filters

[groupsky]

After reviewing the codebase, I've determined this issue is no longer actionable due to architectural constraints.

Analysis

PR #332 successfully implemented --parity and --baud-rate filters for the discover command with comprehensive testing:

• 161 new tests across unit and E2E levels
• 16 E2E tests covering filter validation, combined usage, and error handling
• 100% code coverage for all parsers and filter logic

Architectural Limitation

The emulator's baud rate and parity are transport-level settings (not per-device), meaning each emulator instance can only have one configuration. Creating a fixture with:

• Device 1: ID=1, 9600 baud, none parity
• Device 2: ID=2, 19200 baud, even parity
• Device 3: ID=3, 9600 baud, odd parity

...would require three separate emulator instances on three different serial ports, significantly increasing E2E test complexity and runtime.

Current Test Coverage

The existing E2E tests adequately validate:

• ✅ Filter parsing and validation (single values, ranges, comma-separated lists)
• ✅ Combined filter functionality (--id + --parity + --baud-rate)
• ✅ Error handling for invalid inputs
• ✅ JSON output format
• ✅ Integration with the discover command

The unit tests provide thorough coverage of the filter logic itself, proving filters correctly reduce parameter combinations.

Conclusion

The filter functionality is fully implemented and tested. While a multi-configuration fixture would provide additional validation, the cost/benefit ratio doesn't justify the implementation complexity given the robust unit test coverage already in place.

Closing as the original concern (validating filter functionality) has been adequately addressed through comprehensive unit and E2E testing.