cli: reset command to clear the derived projection

[alsmola]

Adds trailtool reset, the first of the two reset-and-replay primitives from #49 (design in #54, docs/design/cloudtrail-replay.md §4).

Reset empties every derived DynamoDB table (people, sessions, roles, resources, accounts, services, relations, identity-links) plus the ingested-files markers, so the projection can be rebuilt from the CloudTrail log by a later replay. The log is never touched, so a reset is always recoverable by replaying it.

What it does

• Store.Reset truncates each table in place: a key-only Scan (projecting just the primary-key attributes, discovered from the table's schema so no per-table key layout is hardcoded) feeds batched BatchWriteItem deletes. The table and its GSIs stay intact, so live ingestion resumes the moment reset finishes.
• The ingested-files markers are cleared with the rest. Leaving them would make a subsequent replay skip every object and rebuild nothing.
• Missing tables are skipped, not fatal, so reset works on a partially-deployed stack.
• Throttled BatchWriteItem leftovers (UnprocessedItems, a successful response the SDK does not auto-retry) re-submit with capped exponential backoff, honoring context cancellation.

Safety

• Prints the tables and their approximate item counts, then requires a typed yes. --yes skips the prompt for scripting. Empty/EOF input cancels.
• Help notes reset should run while ingestion is quiet: objects written mid-reset may be missed. The intended flow is reset, then replay the range.

Counts in the prompt come from DescribeTable's ItemCount, which DynamoDB refreshes roughly every six hours, so they are estimates (shown with ~). Tests cover the confirmation guard (decline / EOF / yes / --yes), JSON output, table coverage, and the key-projection and chunking helpers.

Replay (the trailtool replay half) is the next slice.

Part of #49.

[alsmola]

Addressed the review items that touch reset:

• [P1] Reset unsafe during live ingestion — reset is now scoped and documented as an offline operation. The help states why: truncation is not atomic across tables, so an object written mid-reset can land split across cleared and not-yet-cleared tables and be double-counted on the next replay. A coordinated rebuild that fences ingestion (pausing the EventBridge rule) is the principled fix, tracked as a follow-up in the design (Design: reset and replay from the CloudTrail log #54 §11). For v1 the offline constraint is the contract.
• Simplification: skip CountItems under --yes — the count query only fed the confirmation prompt, so --yes now skips it entirely (no pointless DescribeTable calls in a scripted reset). New test asserts it isn't called.

The design doc (#54) is updated to match: the reset section now leads with the offline requirement and the cross-table non-atomicity, and lists the ingestion fence as the deferred fix.

This PR is now the base of the stack; #56 (replay) is retargeted onto it, since both previously inserted at the same main.go line. Merge this first.