scarecrow: treat failed RTF label reads as labeled in URL tweet lookup

[Pitchfork-and-Torch]

Problem

GetTweetLabelInfoFromURL walks tweets that share a URL and asks GetTweetRtfLabels whether each already has the interstitial. A failed read was replaced with an empty list, so every tweet looked unlabeled.

Bot 7413 (NSFW_Card_Image_URL_to_Tweet_Verdict) uses those two lists as-is:

• PUT applies NSFW_CARD_IMAGE to notLabeled
• DELETE only removes the label from labeled

After a URL-verdict delete, a Strato miss left the tweet interstitial in place. A miss on PUT could also apply the label when the current state was unknown.

This is the tweet-side counterpart of the already-shipped URL-verdict cleanup fix (fork #8). That change can now fire a DELETE; this lookup was still swallowing the label read that DELETE depends on.

Change

Treat a failed GetTweetRtfLabels read as already labeled (TryOrElse(..., TRUE)). Successful empty reads still count as unlabeled.

• DELETE can still call TweetRtfRemoveLabel when the read fails
• PUT will not apply on an unknown state
• A confirmed empty label set is unchanged

No write-path, TTL, or rule-condition changes.

Tests

This derived feature runs inside Botmaker against internal Strato. There is no in-repo harness. Correctness is the list split plus the bot 7413 apply/remove branches, and TryOrElse already substitutes the backup on a failed future (botmaker/.../TryOrElse.java).

Decision table:

GetTweetRtfLabels	Has label	Before	After
ok	yes	labeled	labeled
ok	no	not labeled	not labeled
error	unknown	not labeled (apply / no remove)	labeled (no apply / remove)

Leftover hunches (not shipped)

• UthDailyAccountLabelsJob midnight fence: start-of-day snapshot, same as the legacy job. Same-day-only labels never appear. Not proven that end-of-day was intended.
• Permanent SpamHighRecall on anchor_campaign_* (and SpamEmbeddingPtosDistilled): siblings use a 30-day TTL. Parser treats missing TTL as no expiry on purpose. Policy vs omission, not proven.