recall: --list LINES hides how much was dropped, and elisions counts different events per mode

Two related accounting problems in the recall store, both surfaced reviewing #3278.

1. recall --list LINES hides how much was dropped. total_lines is computed from the persisted payload, so for a truncated entry the column reports what was stored, not what the command produced:

300-line command, cap 2000:   LINES=27  HIDDEN=27  TRUNC=yes

The three numbers are self-consistent, but there is no way to learn that the original was 300 lines. TRUNC=yes signals that something was lost without the magnitude. byte_size already holds the true content.len() but is written and never read - surfacing it (or carrying a separate stored-lines value) closes this cheaply.

2. elisions counts different events per mode. The sqlite path bumps elisions inside store_inner for every committed row, while the tee path counts only emitted hints. The same workload therefore yields different counts depending on mode, which undercuts the per-mode telemetry split added in this PR. Rows stored without a surfaced hint also consume the max_entries budget, evicting entries the user does hold a hash for.

Start with the recall --list path and the recall store's store_inner implementation, then compare the sqlite and tee paths. Trace how byte_size, total_lines, elisions, and max_entries are handled. Done means truncated listings expose the original size and elisions use consistent accounting across modes, including rows without surfaced hints.