chore(*): skill blocklist visibility and install-meta date follow-ups

[0xKT]

Problem

Two follow-ups from the skill governance work:

1. The legacy catalog listing surface is unfiltered and unmarked. LocalSkillCatalog.list_skills (raven/memory_engine/skill_forge/catalog.py:208), used by the TUI RPC surface, returns blocklisted skills like any other skill. gather_all_skills (raven/memory_engine/skill_forge/catalog.py:444) is deliberately unfiltered so raven skill list can render a [blocked] marker next to blocked-but-present skills, but list_skills consumers get no marker at all: a TUI user cannot tell a blocked skill from an active one.
2. Backfilled install dates are indistinguishable from real ones. write_install_meta (raven/skill_hub/audit.py:57) stamps .install-meta.json into a skill directory once, first install wins. Bundles installed before the stamping feature existed get stamped on their first post-upgrade observation, so their installed_at is the backfill moment, not the true install date, and raven skill list shows it as if it were.

Evidence

• list_skills has no blocklist awareness (no is_blocked / normalize_blocklist on that path), by design for inspection semantics, but nothing downstream re-adds the blocked marker.
• write_install_meta never rewrites an existing stamp, so a backfilled date freezes permanently.

Suggested direction

• Either filter list_skills like the runtime catalog paths, or (more consistent with inspection semantics) pass a blocked flag through so the TUI can render its own marker.
• Mark backfilled stamps (e.g. a "backfilled": true field, or derive installed_at from the bundle directory mtime at stamp time) so the list column can render them as approximate.