Rung 3 of the #376 ratchet: `sas/.sasjslint` promotes noBannedStrings to "error". The rule flags the literal words "error " / "warning " anywhere in a file, comments included, because they turn up in a grep of the SAS log and bury the real messages. Its 13 findings are cleared: - Nine are prose and are reworded, so the sentence both reads normally and stops matching: a truncation that aborts a build, a syntax fault, an abort condition, "only records the failure in work.mp_abort_errds" (four copies of the mp_abort-inside-%include comment), a test description, a hook comment. - Two are the text the user sees. loadfile.sas reports "(mf_abort.error file found)" - the marker file carries the word in its name - and buildtermsas9.sas reports "Some final error in &_program"; both are reworded to say the same thing without the literal, since the text sits in a macro argument where the %str(WARN)ING split does not survive the quoting. - Three keep the word because the word is the content: the doxygen @warning tags in macros/bitemporal_dataloader.sas and the two SAS 9 admin STPs (makedata, makelib). Each carries @sasjslint {"noBannedStrings": false}, as targets/server/services_server/admin/makedata.sas already did. VERIFICATION - `npm run lint:sas`: 5 warnings, 0 errors, exit 0. - `sasjs compile`: succeeds. - Deployed to sas.4gl.io and ran the SAS suite there: `sasjs test` reports "Tests that pass: 64/64 (100%)". The run used a scratch appLoc (/Public/app/dc-lint-ratchet) seeded with makedata, so the shared /Public/app/dc deployment was left alone; the scratch target was removed from sasjsconfig.json before this commit. 5 warnings remain: macro name length (2) and case (2), indentationMultiple (1) - the last rung.