gnucash stable: Multiple changes pushed

[John Ralls]

Updated	 via  https://github.com/Gnucash/gnucash/commit/453a4fe8 (commit)
	 via  https://github.com/Gnucash/gnucash/commit/5dc53303 (commit)
	from  https://github.com/Gnucash/gnucash/commit/13d8da31 (commit)



commit 453a4fe8868d10414bcdbdca28054fbc432debf1
Merge: 13d8da3116 5dc53303b5
Author: John Ralls <jralls at ceridwen.us>
Date:   Sat Jul 11 11:03:53 2026 -0700

    Merge Noah Noerr's 'fix-qofsession-end-releases-lock' into stable.

commit 5dc53303b5b7acfad89a5d32a13c1b7011c5b20b
Author: Noah R <Noerr at users.noreply.github.com>
Date:   Thu Jul 9 12:10:39 2026 -0700

    [engine] qof_session_end: release the lock via the session's backend
    
    qof_session_end() is documented to release the session lock and shut the
    backend connection but it does not release the session lock in all scenarios
    (BUG). qof_session_end() looked the backend up via qof_book_get_backend().
    The book's backend pointer is only set by load() or a data-changing save() (an
    empty book's save() early-returns before attaching it); begin() sets only the
    session's own m_backend. So a session that creates a store and ends it without
    loading or making a real change had a backend on the session but not on the
    book: end() found none, skipped session_end(), and never released the lock --
    it was only released later at destroy().
    
    Because the fault is in backend-agnostic engine code it affects every backend
    that locks at begin(): the SQL/DBI backends leave a stale row in the gnclock
    table, and the XML/file backend leaves an abandoned <file>.LCK sentinel (with
    no data file, since XML data is only written at save). The store then appears
    locked to the next opener.
    
    End the session's own backend (m_backend, always set at begin()) instead. It
    already equals the book's backend whenever the latter is set, so the change is
    a no-op for loaded/saved sessions and additionally covers the
    created-but-not-attached case.
    
    Add regression tests for both backends, each of which begins a create-mode
    session, ends it without a data-changing save, and checks the lock is gone:
      - test-backend-dbi-basic.cpp (test_dbi_new_store_end_releases_lock): reopens
        the store and asserts it is not ERR_BACKEND_LOCKED.
      - test-load-backend.cpp (test_new_store_end_releases_lock): asserts the XML
        <file>.LCK lockfile has been removed.



Summary of changes:
 .../backend/dbi/test/test-backend-dbi-basic.cpp    | 37 ++++++++++++++++++++++
 libgnucash/backend/xml/test/test-load-backend.cpp  | 30 ++++++++++++++++++
 libgnucash/engine/qofsession.cpp                   |  5 ++-
 3 files changed, 69 insertions(+), 3 deletions(-)