standard code suggestion from psycopg gets errors

Describe the bug

Hi,
We use pscopg2 and have the following query:

        # Now to get all user preferences for the user id
        sql_str = 'SELECT "user_preference"."preference_app_id","user_preference"."value", ' \
            + ' "preference_app"."preference_tp_cd", "preference_app"."user_visible" ' \
            + ' FROM "user_preference" INNER JOIN "preference_app" ON ' \
            + ' "user_preference"."preference_app_id" = "preference_app"."preference_app_id" '
        sql_str += ' WHERE "user_preference"."user_data_id" = %s '  # nosec - psycopg standard
        sql_str += ' AND "preference_app"."garage_app_tp_cd" = %s '  # nosec - psycopg standard
        sql_str += ' AND(("user_preference"."start_dt" < current_timestamp and "user_preference"."end_dt" is null) ' \
            + '     OR("user_preference"."start_dt" < current_timestamp and '\
            + '         "user_preference"."end_dt" > current_timestamp)) '
        data = (user_data_id, app_tp_cd)
        

However it a fails bandit security. The code above fails on the first assignment where there is no parameterization at all

>> Issue: [B608:hardcoded_sql_expressions] Possible SQL injection vector through string-based query construction.
   Severity: Medium   Confidence: Low
   Location: src\controllers\preferences.py:113
   More Info: https://bandit.readthedocs.io/en/latest/plugins/b608_hardcoded_sql_expressions.html
112             # Now to get all user preferences for the user id
113             sql_str = 'SELECT "user_preference"."preference_app_id","user_preference"."value", ' \
114                 + ' "preference_app"."preference_tp_cd", "preference_app"."user_visible" ' \
115                 + ' FROM "user_preference" INNER JOIN "preference_app" ON ' \

Further the lines with %s are following the guidelines from psycopg2 as how to do parameterized queries. and need exceptions
```
sql_str += ' WHERE "user_preference"."user_data_id" = %s ' # nosec - psycopg standard
sql_str += ' AND "preference_app"."garage_app_tp_cd" = %s ' # nosec - psycopg standard

### Reproduction steps

```bash
1.Create file bandit_tst.py
2.Paste the following code
# Now to get all user preferences for the user id
sql_str = 'SELECT "user_preference"."preference_app_id","user_preference"."value", ' \
    + ' "preference_app"."preference_tp_cd", "preference_app"."user_visible" ' \
    + ' FROM "user_preference" INNER JOIN "preference_app" ON ' \
    + ' "user_preference"."preference_app_id" = "preference_app"."preference_app_id" '
sql_str += ' WHERE "user_preference"."user_data_id" = %s '  # nosec - psycopg standard
sql_str += ' AND "preference_app"."garage_app_tp_cd" = %s '  # nosec - psycopg standard
sql_str += ' AND(("user_preference"."start_dt" < current_timestamp and "user_preference"."end_dt" is null) ' \
    + '     OR("user_preference"."start_dt" < current_timestamp and '\
    + '         "user_preference"."end_dt" > current_timestamp)) '

3.Save
4. Run bandit -r on the root directory and this error shows up
Test results:
>> Issue: [B608:hardcoded_sql_expressions] Possible SQL injection vector through string-based query construction.
   Severity: Medium   Confidence: Low
   Location: src\controllers\bandit_tst.py:2
   More Info: https://bandit.readthedocs.io/en/latest/plugins/b608_hardcoded_sql_expressions.html
1       # Now to get all user preferences for the user id
2       sql_str = 'SELECT "user_preference"."preference_app_id","user_preference"."value", ' \
3           + ' "preference_app"."preference_tp_cd", "preference_app"."user_visible" ' \
4           + ' FROM "user_preference" INNER JOIN "preference_app" ON ' \
...

Expected behavior

Expect no problem with the above code

Bandit version

1.7.0 (Default)

Python version

3.9 (Default)

Additional context

No response

Reproduce the B608 finding with the bandit_tst.py example and inspect the B608 check referenced by the issue. Compare its result with the query construction in src/controllers/preferences.py; done means the psycopg2-style parameterized query no longer produces the reported false-positive finding while genuine hardcoded SQL risks remain detectable.