The dark_threshold config comment causes systemic confusion for IR-camera users. Five years of issues — #418, #725, #884, plus the enhancement request #727 — boil down to users reading

The lower this setting is, the more dark frames are ignored

as "lower is better for dark rooms," then ending up with an even stricter threshold than the default and login failing more often, not less.

The comment is technically correct (lower threshold = more frames marked as dark and skipped) but the natural-language ambiguity is hard to escape without first understanding the histogram-bucket math in compare.py.

What this PR changes

Documentation only. Rewrites the comment to:

• Lead with what the value means — rejection threshold for the percentage of near-black pixels in a frame.
• State direction explicitly — higher tolerates darker rooms, lower rejects more frames.
• Note the IR-camera case — the default is calibrated for visible-light webcams; pure-IR cameras in dim rooms commonly read 80-95% near-black pixels (face is lit by the IR emitter, background stays unlit) and need this raised to 80-95.

The default value (60), the underlying computation, and runtime behavior are all unchanged.

Why this is worth merging

• Zero behavior risk (comment-only).
• Addresses recurring user confusion documented in Dell XPS 13 (9300) - "Face Detection Image Too Dark" error during daylight #418, Frames very dark at low light #725, IR emitter doesn't turn on/ stops if room is too dark. #884 (does not close them — those issues span more than just the comment, but this is the doc-side fix).
• Makes Auto-detect dark threshold #727 ("auto-detect dark threshold") less urgent by making the manual case discoverable.