Reorganize historical download reliability context

Author: jessuppi

docs/malware-rumors.md

@@ -102,7 +102,9 @@ slick.fyi/crons/01-cron-minutely.txt
 
 can forward to the corresponding raw file in the public SlickStack GitHub repository.
 
-This abstraction was intentional. GitHub has experienced outages, availability problems, and raw-file restrictions over the years. Using a stable SlickStack endpoint means the project can redirect retrieval to GitLab or another public mirror if GitHub becomes unavailable without requiring administrators to manually repair every SlickStack server first.
+This abstraction was intentional. Earlier SlickStack infrastructure relied primarily on assets hosted through GitHub Pages, and SlickStack deliberately made those assets available over both HTTP and HTTPS at the time. SlickStack also retrieved raw files from GitHub using unauthenticated `wget`, where intermittent failures became an operational concern; the project documented blank or NULL responses in 2021 and later investigated GitHub's undocumented raw-file rate limits and authentication options, including in a [public Stack Overflow discussion](https://stackoverflow.com/questions/66522261/does-github-rate-limit-access-to-public-raw-files).
+
+GitHub has also experienced outages, availability problems, and raw-file restrictions over the years. Using a stable SlickStack endpoint means the project can redirect retrieval to GitLab or another public mirror if GitHub becomes unavailable or unreliable without requiring administrators to manually repair every SlickStack server first. Upstream download failures could otherwise interrupt unattended requests and prevent expected maintenance or recovery actions from completing.
 
 The domain is also operated with normal HTTPS and DNS security measures, including DNSSEC.
 
@@ -122,9 +124,9 @@ That history is public in the Git repository.
 
 The option existed for compatibility rather than to conceal the destination of downloads.
 
-SlickStack historically supported older Ubuntu LTS releases where `wget` depended on older system certificate stores and TLS libraries. During that period, HTTPS compatibility changes and certificate-chain issues could cause otherwise valid unattended downloads to fail certificate verification. Earlier SlickStack infrastructure relied primarily on assets hosted through GitHub Pages, and SlickStack deliberately made those assets available over both HTTP and HTTPS at the time. As SlickStack also retrieved raw files from GitHub using unauthenticated `wget`, intermittent failures became an operational concern; the project documented blank or NULL responses in 2021 and later investigated GitHub's undocumented raw-file rate limits and authentication options, including in a [public Stack Overflow discussion](https://stackoverflow.com/questions/66522261/does-github-rate-limit-access-to-public-raw-files).
+SlickStack historically supported older Ubuntu LTS releases where `wget` depended on older system certificate stores and TLS libraries. During that period, HTTPS compatibility changes and certificate-chain issues could cause otherwise valid unattended downloads to fail certificate verification.
 
-That presented a practical problem for an automated server stack: a failed certificate check or upstream download could interrupt an unattended request and prevent the expected maintenance or recovery action from completing.
+For an automated server stack, a failed certificate check could interrupt an unattended download and prevent the expected maintenance or recovery action from completing.
 
 Using `--no-check-certificate` was therefore a compatibility tradeoff.