[TomyCesaille]

Closes #16.

Shared fetch (fetch_report in prtop/cli.py, prtop/state.py): every fetch saves its report to report.json in the state directory. That covers the live view, a one-shot table and prtop watch. The save carries the settings the fetch ran under (repr(config)) and the time it came back. A prtop about to fetch less than 10 seconds later (FRESH_FOR), under the same settings, shows that report instead of calling glab or gh.

• The window is fixed rather than tied to the watch's -d, as the issue proposed. The lag stays under 10 s whatever the loops' delays, and a closed or paused live view never leaves a watch reading an old table.
• Beside the live view, which fetches every 30 s, about one watch check in three falls in the window and makes no calls. Two one-shot tables or two watches seconds apart share one fetch.
• A reused report never moves the merge-detection baseline in <host>.json. Only the fetch that called the forges does.
• The live view honours the same window: Ctrl+L within 10 s of the last fetch, or -d under 10, shows that fetch again.
• A save dated in the future (the clock moved back), a missing one and a malformed one all read as no save. --demo neither reads nor saves.
• examples/claude-code/CLAUDE.md drops the advice to skip the watch while prtop is open.

Tried with a fake glab and gh that log every call: a second prtop right after the first logged 0 calls, and a third 10.5 s later fetched again.