fix: refresh install metadata after repository pushes

[labmimors]

What changed

• Re-probe install metadata on the next daily sync when a repository has been pushed since its last install probe; inactive repositories keep the seven-day fallback.
• Keep plugins.install_cmd strictly operator-owned. Probing refreshes only the automatic facts and install_cmd_auto; it never clears or overwrites a curated command.
• Stop a live database null from falling back to a stale build-time editorial install-command snapshot. If Turso is unavailable, the existing safe behavior remains: show the unknown/README guidance instead of an old command.
• Add direct regressions for push-triggered row selection, live-null display behavior, and the ambiguous case where an intentional curated pin happens to equal an earlier automatic command. Equality is not treated as provenance.

There is no repository-specific branch or product allowlist in this change.

Why

Install facts can change much faster than the previous seven-day probe window. A new package publication, release, or README install path should be reflected in automatic metadata after the repository is pushed, without weakening the operator-override contract.

The live labmimors/dsh-mcp-lens page currently demonstrates both layers of the lifecycle: its curated primary command still points to rc.7, while the repository root and npm metadata are rc.9 and the README advertises dsh-mcp-lens@next. This PR deliberately does not guess whether the rc.7 override is accidental. After merge and the next sync, the automatic record can refresh promptly, but the visible curated rc.7 pin still requires an operator to clear or update it. The existing follow-up on issue #3 requests that data correction.

Safety boundaries

• probe-install.mjs never writes install_cmd, including when its value equals a previous install_cmd_auto value.
• Manual multi-step commands, extra flags, profile choices, and version pins remain untouched.
• The push check uses the existing ISO timestamps refreshed by the preceding sync:db step; stale-time probing remains as a fallback.
• No tarball is downloaded, unpacked, or executed.

Validation

• pnpm test — 24/24 pass, including an in-memory query test for pushed_at > install_probed_at, a live-null/no-editorial-fallback test, and the intentional-equal-pin write guard.
• ESLint on every changed JS/TS/TSX file — pass.
• pnpm exec next typegen — pass.
• pnpm exec tsc --noEmit — pass.
• pnpm build — pass using the documented static fallback because Turso credentials were intentionally absent.
• git diff --check — pass.
• Live public metadata checked: page still renders rc.7; root manifest and npm latest / next are 0.1.0-rc.9; README hint is dsh-mcp-lens@next.

Full-repository pnpm lint still reports five pre-existing errors in lesson-progress.tsx, locale-switcher.tsx, theme-toggle.tsx, typewriter.tsx, and registry.ts; none is touched here. The Vercel PR status currently points to a deployment-authorization page rather than a code/test failure.

Disclosure

I maintain labmimors/dsh-mcp-lens, which exposed this stale-metadata path. The change is repository-agnostic and does not request featuring or ranking treatment.

[vercel]

@sluckyli2023 is attempting to deploy a commit to the hikariming's projects Team on Vercel.

A member of the Team first needs to authorize it.