181 fs: fail-soft tags in src/ have had no reader since #1318, and they have drifted #1949

Found by the v0.47.0 release legibility review (#1938).

src/ carries 181 fail-soft classification tags: fs:ANSWER, fs:CHANNEL, fs:EMPTY, fs:LITERAL, fs:STRICT, fs:TLS, fs:TODO and fs:VOID (git grep -ohE 'fs:(ANSWER|CHANNEL|EMPTY|LITERAL|STRICT|TLS|TODO|VOID)' -- src | wc -l). They were the input of tools/failsoft_classify_check.sh, which #1318 deleted (94c4c5b, 645 lines). The answer half moved to the PINS table of tools/strict_differential.sh (:765, "documented answers must not raise under strict"). Since then nothing reads the tags (git grep finds no reader outside src/), so they are unenforced claims, and they have already drifted:

• src/builtins_host.c write_text and write_bytes carried fs:ANSWER over a NULL-FILE* branch that File builtins expose no error reason (errno): guests cannot report "No such file or directory" #1668 turned into a raise. The review fixed those two (commit ae92da2 on release-0.47.0-review).
• src/ext_http.c:1035 and :1045 carry fs:TODO #971 ... deferred, but Numerics: arithmetic invalidity is observer-blind — route it through the observer and finish the fail-soft→loud reform (~89 guards) #971 is closed and the guards still answer silently (http: shared_has and shared_delete answer false/0 for a non-string key instead of raising #1947).

A tag with no reader reads like a classification someone checked. Either it stops looking like one, or something checks it again.

Done when

• Either the fs: prefixes are removed from src/ (any explanation still true stays as an ordinary comment, and a soft answer that matters has a PINS row in tools/strict_differential.sh), or a checker reads the tags again and a planted wrong tag goes red through it.
• In the first case, git grep -cE 'fs:(ANSWER|CHANNEL|EMPTY|LITERAL|STRICT|TLS|TODO|VOID)' -- src prints nothing.