Fix %reset -f not starting a new session

Fixes #13087.

%reset -f is documented as a hard reset that gives you a new session, and the magic's docstring shows the prompt going back to In [1]. Instead the prompt counter kept counting (In [35] → In [36]) and no new history session was created.

Root cause

The hard-reset branch of the %reset magic called self.shell.reset(new_session=False, ...), so InteractiveShell.reset neither opened a new history session nor reset execution_count to 1. The False dates back to b24bd65 (2011), which also changed the magic from new_session=True; maintainer MrMino confirmed on the issue that this is a regression against the docstring. The only other caller passing False is _atexit_once, where no new session is wanted because the shell is exiting; it is untouched. The soft-reset path (-s) does not call shell.reset at all and is unaffected.

Fix

Pass new_session=True in the hard-reset branch, restoring the documented behavior: the namespace is cleared, a new history session starts, and the next prompt is In [1].

Tests

New regression test test_reset_starts_new_session in tests/test_magic.py: after two cells, %reset -f leaves execution_count == 1, starts a new history session, clears the namespace, and the next cell is numbered In [1]. The test fails on unmodified code (assert 3 == 1 for the prompt counter).

test_save_with_no_args also starts a fresh history session at the end: it stores inputs with hardcoded line numbers 1-4 in the shared test shell, and with the counter now restarting at 1, later cells could reuse those line numbers in the same session and trip the history database's UNIQUE(session, line) constraint. The extra reset isolates the faked entries.

AI usage

Worked on with Muse (Muse Spark 1.3); reasoning effort level unknown.