fix: parallel restoreTopLevelResponseStorage with the !handled splice

Greptile flagged this as the only remaining P1 on PR #473 (their
"Confidence Score: 4/5" anchor): restoreTopLevelModelProvider got the
post-loop `!handled && originalLine` splice in fd8097e, but the
parallel restoreTopLevelResponseStorage was left without it. If the
bind-written `disable_response_storage = false` line was stripped from
config.toml between bind and unbind, the user's original
`disable_response_storage = true` setting was silently lost.

Mirror the fix: when nothing in `currentConfig` matched the top-level
disable_response_storage line, splice the originalLine in before the
first section header so it lands in the root table (a tail append
would land it inside whatever [section] comes last and break TOML
semantics).

Adds two regression cases to test/config-toml-restore.test.ts —
"splices the original line before the first section when current omits
it" pins the splice path; "appends the original line at tail when
current has no section header" pins the no-section fallback.

Local verification:
- npx vitest run on config-toml-restore + app-bind + uninstall-command
  + preuninstall → 64/64 pass.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>