fix(security): Use bounded parameters for reserved-tag init

[reddraconi]

Summary

The startup migration that bumps tags-table autoincrement past the reserved range is built from a pair of SQL statements using f-strings.

While RESERVED_TAG_END is hard-coded at the moment, it's a scary pattern that can turn into a SQL injection site if that value ever originates from another location.

I swapped the tag_id to a SQLAlchemy bind paramter (:tag_id) to fix that and so it matches the other queries in the codebase.

This really just amounts to a code smell that could be a footgun in the future.

Why no new tests

This a simple refactor with no behavioral changes.

make_tables(engine) is already exercised through every library-creating fixture in the existing test suite.

Tasks Completed

• Platforms Tested:
  • Windows x86
  • Windows ARM
  • macOS x86
  • macOS ARM
  • Linux x86
  • Linux ARM
• Tested For:
  • Basic Functionality
  • PyInstalled Executable
  • pytest 231 tests still pass
  • ruff check src/tagstudio tests
  • mypy on changed files

[TrigamDev]

• This is not an issue currently, and is only an issue if, for some insane reason, the user is allowed to define arbitrary input for internal constants that will not change. Why would that change be made?
• Given your prior use of AI for pull requests, it's coming off as though you're just asking an AI to "find issues and fix them". Hell, the PR message reads exactly as though it was AI generated. This is not something causing issues presently, and has little chance to in the future. There are actual issues that need attention, digging up non-issues does not help.

[reddraconi]

I mentioned that in the body it's a very minor thing. If there's never a a plan to move RESERVED_TAG_END out of constants, then cool. It's probably just more of personal issue for me when SQL statements are built with f-strings.

After I resumed working on issue #1247 this week, I felt like I got to go a good stopping point and wanted to double-check I didn't miss anything that might be helpful. If you'd like to toss this PR, that's cool, too.

[TrigamDev]

• This is not an issue currently, and is only an issue if, for some insane reason, the user is allowed to define arbitrary input for internal constants that will not change. Why would that change be made?

  • Given your prior use of AI for pull requests, it's coming off as though you're just asking an AI to "find issues and fix them". Hell, the PR message reads exactly as though it was AI generated. This is not something causing issues presently, and has little chance to in the future. There are actual issues that need attention, digging up non-issues does not help.

Also not to mention, TagStudio is a local program only, SQL injection isn't a security issue as the user has access to the database file already, they would get zero benefit from using SQL injection on data they already have access to. And even then, TagStudio stores no sensitive data.

[reddraconi]

I think my cyber hat is cutting off circulation today and marking this as security was a bit dramatic. I was just looking at the SQL handling stuff and forgot this is local-only. What would you like to do with this and the PR?

If you want me to submit it a simple code consistency cleanup, I'll be happy to do that, or we can just schwack all of it.