Restore reliable catalog generation, RSS, and Pages deployment

[rainmana]

What changed

• removes third-party README bodies from generated and durable public state
• adds a deterministic 1,070-record recovery catalog with integrity manifest
• hardens fetch, summarization, configuration, recovery, and atomic page generation
• replaces the broken feed with a safe, bounded, tool-only RSS implementation
• adds CI and repairs the GitHub Pages deployment workflow with pinned actions
• adds a comprehensive README changelog, recovery journal, and reusable template guide

Why

The previous pipeline depended on disposable SQLite cache state and copied untrusted upstream README content into Hugo pages. One upstream script payload caused Hugo minification and deployment to fail repeatedly, while RSS accumulated oversized and incorrectly dated entries.

Impact

A clean GitHub runner can now reproduce all 1,070 known tool pages from checked-in durable state, publish a standards-friendly 50-item feed, and safely resume discovery/summarization without exposing upstream README content.

Validation

• go test ./... -count=1 with Hugo Extended 0.164.0
• go vet ./...
• CLI build
• actionlint for both workflows
• Go formatting and Git diff checks
• pinned-action and secret-pattern checks
• production Hugo build with 1,070 verified tool routes
• RSS validation: 50 ordered entries, absolute unique GUIDs, bounded safe summaries
• final Joern CPG verification: no README-to-generated-page dataflow

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 77bf754671

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve stem matching for short category keywords

Restricting every alphanumeric keyword of four characters or fewer to whole-token matches breaks intentional stem rules in the default configuration. For example, the scan rule no longer matches descriptions containing “scanning,” and wifi no longer matches “WiFi6,” so these repositories fall into unrelated or default categories despite previously matching. Apply boundary matching only to collision-prone keywords such as rat, rather than using keyword length as a blanket criterion.

Useful? React with 👍 / 👎.