`conditional-lm-fresh-no-lm` inverted its design intent (#98 item 4): the stored `Date` is later than the IMS, so both RFC-directed evaluations yield 200, not the expected optimal-304

[shruggingatlas]

While transpiling this suite into decision-trace conformance fixtures (gitlab.com/g6302/lintology, crates/lintology-rfc9111), we found that conditional-lm-fresh-no-lm (tests/conditional-lm.mjs) expects behavior that contradicts both RFC-directed evaluations — and, we believe, the test's own design intent:

1. The design checklist. IMS #98 (2020-10-12) item 4 specifies the shape: "on a response with no LM but an earlier date" — i.e., a stored Date earlier than (or equal to) the If-Modified-Since value, where RFC 9111 §4.3.2's fallback ("a cache SHOULD use the stored response's Date field value ... to evaluate the conditional") yields 304, fully RFC-consistently.

2. The implementation inverted the offsets. 5f31acd (2020-10-17) shipped Date: 0 with If-Modified-Since: -3000 (magic_ims resolves it against the previous response's server-now), so the stored Date is 3000 seconds later than the IMS value. Under RFC 9110 §13.1.3's evaluation, the fallback modification date is then later than the field value → condition true → the directed serve is the full 200. The other normative path agrees: with no modification date available, §13.1.3's base rule is to ignore IMS → again the full response.

3. The judgment flip came later, in a bulk pass. The test was born as kind: 'check' with a question-phrased title ("Does HTTP cache respond ... ?") — a behavior observation, not an assertion. Three days later, 1bcd984 ("a pass at updating tests") retitled it to the assertive "An optimal HTTP cache responds ..." and flipped kind to 'optimal', with the inverted offsets never revisited.

The sibling tests are all RFC-consistent (conditional-lm-fresh / -earlier have LM ≤ IMS; -rfc850's LM equals its IMS instant), so this appears to be a one-test inversion rather than a considered position.

Suggested fix, matching #98's intent: date the IMS later than or equal to the stored Date (e.g. keep Date: -3000 on the stored response, or send If-Modified-Since: 0), keeping the no-LM fallback under test with an expected 304 that the RFCs direct. Alternatively, expect the full 200 and rename.

For context: this is the one conditional-family member we had to exclude from transpilation, because a validator implementing §4.3.2's directed evaluation fires on the test's expected conduct.