Add entry-status and function-entries for cache introspection

[lvh]

Summary

• Adds entry-status — looks up a single cache entry by cached-fn + args, returning :created-at, :last-hit, :hits, :cold?, :stale? (or nil if no row)
• Adds function-entries — returns the same fields for every live entry belonging to a cached-fn, plus deserialized :args for table display
• Both use the same args-cache-key + serialization path the cache already uses internally, so callers don't duplicate that logic or touch the schema directly

Test plan

• bb test passes (258 assertions, 0 failures)
• Verify entry-status returns nil before the cached fn is called, a populated map after
• Verify :cold? / :stale? reflect the configured TTL / max-age correctly
• Verify function-entries returns one entry per distinct arg set

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e56fdbd99a

ℹ️ 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]

Compute cold/stale flags from each row's TTL values

entry-status (and similarly function-entries) derives ttl/max-age from cached-fn metadata instead of the row being inspected, so :cold? and :stale? can be wrong when the same cache DB contains entries written under older settings (for example after deploying with new TTLs). The cache’s read/expiry logic uses per-row :ttl/:max-age, so these introspection flags can disagree with actual eviction behavior; selecting :ttl and :max-age from the row would keep status reporting accurate.

Useful? React with 👍 / 👎.

[lvh]

Code-review note from a consumer:

entry-status looks up via (-> cache-args seq args-cache-key ser/serialize), while the store path in cached does (args-cache-key args) directly (where args is a rest-arg list). For the default :args-cache-key identity + a 0-arity cached fn, this is a mismatch:

• store: args is (), so the row is keyed on (ser/serialize ())
• lookup: (seq []) is nil, so the key becomes (ser/serialize nil)

Different serialized bytes ⇒ entry-status returns nil even when a matching row exists.

Doesn't affect my use case — I'm passing (constantly [version]) as :args-cache-key, which ignores its input — but consumers leaning on the default would see misses. Suggest dropping the seq call (or (or (seq cache-args) ())) so empty arg-lists round-trip the same way the store path keys them.

[lvh]

Above comment has been addressed.