The `Update SchemaStore` run for the `4.54.0` tag failed at the push
step with `refusing to allow a Personal Access Token to create or update
workflow .github/workflows/auto-update.yml without workflow scope`. The
`SCHEMASTORE_TOKEN` PAT carries `repo` scope only, which is correct for
our use case, so the workflow itself has to stop pushing upstream
workflow file changes through the fork.

The root cause is that `gh repo fork --clone` does not sync the fork
when it already exists, so `upstream/master` was ahead of
`origin/master` by upstream commits that touched
`.github/workflows/auto-update.yml`. Force-pushing the
`update-tox-schema` branch — built from `upstream/master` — carried
those workflow edits into the fork, which trips GitHub's workflow-scope
guard.

The fix calls `gh repo sync` on the fork's `master` first (the Sync API
path only requires `repo` scope), then bases the working branch off
`origin/master`. The resulting push contains a single new commit
touching `src/schemas/json/tox.json`, so no workflow files cross the
boundary.

<!-- Thank you for your contribution!

Please, make sure you address all the checklists (for details on how see
[development
documentation](http://tox.readthedocs.org/en/latest/development.html#development))!
-->

Ghostty uses `TERMINFO`, instead of installing into the `terminfo`
database, to advertise terminal capabilities. The Ghostty docs instructs
users to configure tools (e.g. `ssh`) which sanitize their environment
variables to preserve this variable.

Without this change, I'm seeing

```console
$ tox -e 3.14
3.14: uv-sync> /Users/work/.local/share/uv/tools/tox/bin/uv sync --locked --python-preference system --no-default-groups --group tests -p cpython3.14
3.14: commands[0]> coverage run -m pytest tests
No entry for terminal type "xterm-ghostty";
using dumb terminal settings.
================ test session starts ================
platform darwin -- Python 3.14.5, pytest-9.0.3, pluggy-1.6.0
```

Ghostty docs: https://ghostty.org/docs/help/terminfo

- [x] ran the linter to address style issues (`tox -e fix`)
- [x] wrote descriptive pull request text
- [x] ensured there are test(s) validating the fix
- [x] added news fragment in `docs/changelog` folder
- [ ] updated/extended the documentation

---------

Signed-off-by: Edgar Ramírez Mondragón <edgarrm358@gmail.com>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

Co-authored-by: Bernát Gábor <bgabor8@bloomberg.net>

When both `constraints` and `constrain_package_deps = true` are
configured, tox passes two `-c` flags to pip during
`install_package_deps`: one for the user's constraints file and one for
the auto-generated constraints file. 🔧 pip merges constraints from
multiple files via specifier intersection, so overlapping packages with
different versions produce unsatisfiable constraints and a resolver
error.

The `constraints` option already applies to both `install_deps` and
`install_package_deps` phases, making `constrain_package_deps` redundant
when it is set. This change skips generating and applying the
auto-generated constraints file whenever user constraints are
configured. The three affected code paths (non-frozen write, frozen
write, and package_deps application) all gate on a new
`_has_constraints` property that checks whether the user provided
constraint content.

Users who currently set both options will see the same effective
behavior, minus the conflicting duplicate `-c` flag. If they relied on
auto-constraining for packages absent from their constraints file, they
should add those pins to their constraints file directly.

Fixes #3945

---------

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>