fix(nudges): a configured threshold must never degrade to permissive

[Mukller]

Closes #548

Problem

compress.minContextLimit accepts a percentage string, and a percentage can only become a token count once the host has reported the model context window. Until then resolveContextTokenLimit returned undefined, and isContextOverLimits collapsed that into:

const overMinLimit = minContextLimit === undefined ? true : currentTokens >= minContextLimit

A configured "15%" therefore behaved exactly like no threshold at all, and the turn/iteration nudges fired from the first request of a session. That is the reported symptom: compression starting at roughly 4% of the window with minContextLimit: "15%".

The same degradation happens when:

• the value is unparseable ("not-a-number" yields NaN and falls through to undefined)
• a per-model override in modelMinLimits exists but its key does not match the current provider/model

The upper limit already failed closed, which is why only the lower one misbehaved — the asymmetry is the tell.

Change

A limit that was configured is now distinguished from one that was never configured:

state	overMinLimit
configured and evaluable	compared against current usage, unchanged
configured but not evaluable	false — no nudge is injected
never configured	true — the existing permissive default

So a threshold DCP cannot evaluate yet fails closed, which is the behaviour the user asked for when they set it, and a typo in the config no longer silently enables compression.

Verification

tests/nudge-thresholds.test.ts:

• minContextLimit: "15%" with the model context window not yet reported → overMinLimit === false
• minContextLimit: "not-a-number" → overMinLimit === false
• a resolvable threshold still compares correctly in both directions, and overMaxLimit is unaffected

The first two fail on the current implementation with percentage threshold silently became permissive.

Full suite 122 passing on this branch, tsc --noEmit clean, prettier --check clean.