Not sure whether the 'remnant' concept is necessary. Instead could we just remove must-filter fields that have been satisfied?

I think it is necessary to handle the case where the bypass field is selected, but the must-filter fields are not selected.

Imagine this setup

Table: EMP (empno, name, id)
must_filters: empno
bypass_filter: name

Query:
select * from (select name from emp) where name = 'bob'

The inner query select name from emp can't error on empno not being filtered at this point because name was selected, and could be filtered on later. The must-filter for empno is not satisfied yet at this point.

When we get to the select * from _ where name = 'bob', that's where we defuse the error for empno based on seeing name being filtered on.

If alternatively the query was
select * from (select name, id from emp) where id = '12'
When we get to select * from _ where id = '12', we're at the top-level, and remnantMustFilter's set is not empty, hence we throw an error.

After revising and simplifying the 3 fields mustFilterFields, mustFilterBypassFields and remnantMustFilterFields into a single class, I was able to simplify away the interface and no longer need to expose getRemnantFilterFields to users of SemanticTable. I'll push new commits soon.

I see. If t has a must-filter field f and bypass fields b0 and b1, then the query select b0, b1 from t has no must-filter fields, no bypass fields, but two remnant fields [b0, b1].

If you filter on any of those remnant fields then they all go away.

Actually that is not how the sets are populated.
The purpose of remnant fields is to capture the fields that were marked as required, but no longer accessible to be filtered on and defused in the select clause. In other words, you cannot filter on any of the remnant fields. The presence of values being in the remant-filter set serves the purpose of being an indicator for erroring.

They can only be defused if any of the bypass fields are filtered on.

In your example this would be the correct set values:
select b0, b1 from t where f is a must-filter field

must-filter field: []
bypass-fields: [b0, b1]
remnant-fields: [f]

Must the class be public?

Class names should not be plural (except utility classes). It becomes problematic to name collections of such classes.

'Must' and 'Requirement' seem redundant. So I suggest 'FilterRequirement'.

Maybe mustFilterFields → filterFields, mustFilterBypassFields → bypassFields; remnantMustFilterFields → filterAnyFields.

Could the fields be final? (Public final fields are fine, but if you must have non-final fields they should probably be private.)

Immutable classes are much easier to reason about. Consider adding 'withXxx' methods.

It could be package-private.
I'll rename it to FilterRequirement and filterFields, bypassFields.

Still thinking about the rename of remnantMustFilterFields ... I still think the name needs to capture the connotation that they're valid filter requirements left-over from a previous query, but also distinct from the set that can actively be defused