Remove duplicate query logging that breaks Django's assertNumQueries

[federicobond]

The SqlCommenter _QueryWrapper manually appends the SQL string to queries_log when a CursorDebugWrapper is active. However, CursorDebugWrapper.debug_sql already logs the query as a dict with "sql" and "time" keys. This causes two problems:

1. Queries are double-counted in queries_log
2. The raw string entries cause a TypeError in Django's assertNumQueries, which expects dict entries with a "sql" key

Remove the manual append and let Django handle query logging.

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

• Tested against a Django project that was failing a test case:

         with self.assertNumQueries(14):
              ^^^^^^^^^^^^^^^^^^^^^^^^^
     E   TypeError: string indices must be integers, not 'str'

Does This PR Require a Core Repo Change?

• Yes. - Link to PR:
• No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[tammy-baylis-swi]

Thanks for catching this! Could unit test coverage be added here on OTel Contrib side? Maybe it could borrow from your other-project test case that does the self.assertNumQueries(14).

[federicobond]

@tammy-baylis-swi I tried but found it hard to come up with a meaningful test that it does NOT mess with the query log. Could be something like this, but still feels a bit artificial:

connection = MagicMock()
connection.queries_log = deque()
connection.force_debug_cursor = False

with CaptureQueriesContext(connection) as ctx:
    qw_instance = _QueryWrapper(requests_mock)
    execute_mock = MagicMock()
    context = {"cursor": MagicMock(), "connection": connection}
    qw_instance(
        execute_mock, "SELECT 1", MagicMock(), MagicMock(), context
    )

self.assertEqual(len(ctx), 0)

[tammy-baylis-swi]

@tammy-baylis-swi I tried but found it hard to come up with a meaningful test that it does NOT mess with the query log. Could be something like this, but still feels a bit artificial:

Agree that it's quite mock-y @federicobond , which reminds me that we've been wanting to add proper db client testing for a while but haven't gotten to it with all else going on: #3032

Maybe a quick unit test is better than nothing for now? Would be good to get other Approvers' thoughts.

[federicobond]

I'm not sure it's worth it to add a test here to be honest. There was never a test for the original query log behavior to begin with.