ci(devcontainer): Debian 13 Trixie + Python 3.14, modernize VS Code settings, drop .vscode

[priya-sundaram-dev]

Describe your change:

Modernizes the .devcontainer/ configuration as requested in #15081, plus a recommendation on .vscode/.

Base image — Debian 13 "Trixie" + latest CPython

• VARIANT: 3.13-bookworm -> 3.14-trixie (Debian 13 Trixie, Python 3.14 = current latest-stable CPython).
• Migrated the image path from the deprecated mcr.microsoft.com/vscode/devcontainers/python to the current mcr.microsoft.com/devcontainers/python.
• Note on "plain Python 3": the Trixie image tags are published per minor version (3.11-trixie ... 3.14-trixie) — there is currently no floating 3-trixie alias (the bare 3 tag still resolves to 3-bookworm). So to get both Trixie and the newest interpreter I pinned 3.14-trixie; the comment tells future maintainers to bump it when a newer stable ships.

Free-threaded CPython & .python-version
You asked whether we can pull the latest free-threaded build, or have the devcontainer read .python-version. Two honest constraints:

1. The base devcontainer images do not publish free-threaded (t) variants, so there's no 3.14t-style tag to point VARIANT at.
2. devcontainer.json build.args are not templated — they can't read .python-version at build time.

The clean bridge is the tool we already standardize on: uv reads .python-version. .python-version is 3.14t, so uv sync / uv run inside the container will provision and use free-threaded 3.14t regardless of the base image's interpreter. I added uv to the Dockerfile's pipx install so it's ready out of the box — contributors get free-threaded 3.14t via uv run without us needing a non-existent free-threaded base tag.

VS Code settings modernization

• Dropped the removed/deprecated python.linting.* and python.formatting.blackPath/mypyPath settings (the Python extension no longer honors these; linting/formatting moved to dedicated extensions).
• Added the Ruff extension (charliermarsh.ruff) and wired format-on-save + source.fixAll/organizeImports for [python], matching the repo's actual linter/formatter.

.vscode/ recommendation
The directory held a single setting — githubPullRequests.ignoredPullRequestBranches: ["master"] — which is a personal convenience for the VS Code GitHub-PR extension, not project tooling. Since pre-commit + Ruff already cover formatting/linting for everyone, I went with your inclination and deleted .vscode/ in this PR. It's a genuine judgment call, though: if you'd rather keep that one line so the PR extension doesn't treat master as a reviewable branch, I'm happy to restore just that file.

@cclauss — happy to split any of these (base bump / settings / .vscode delete) into separate PRs if you'd prefer smaller units.

• Add an algorithm?
• Fix a bug or typo in an existing algorithm?
• Add or change doctests? -- Note: Please avoid changing both code and tests in a single pull request.
• Documentation change?

Checklist:

• I have read CONTRIBUTING.md.
• This pull request is all my own work -- I have not plagiarized.
• I know that pull requests will not be merged if they fail the automated tests.
• This PR only changes one algorithm file. To ease review, please open separate PRs for separate algorithms.
• All new Python files are placed inside an existing directory.
• All filenames are in all lowercase characters with no spaces or dashes.
• All functions and variable names follow Python naming conventions.
• All function parameters and return values are annotated with Python type hints.
• All functions have doctests that pass the automated testing.
• All new algorithms include at least one URL that points to Wikipedia or another similar explanation.
• If this pull request resolves one or more open issues then the description above includes the issue number(s) with a closing keyword: "Fixes #ISSUE-NUMBER".

[algorithms-keeper]

Closing this pull request as invalid

@priya-sundaram-dev, this pull request is being closed as the files submitted contains an invalid extension. This repository only accepts Python algorithms. Please read the Contributing guidelines first.

Invalid files in this pull request: .devcontainer/Dockerfile

[priya-sundaram-dev]

Heads-up: algorithms-keeper auto-closed this for an "invalid extension" on .devcontainer/Dockerfile — the same file-extension whitelist limitation that closed the uv.lock PRs earlier (a Dockerfile has no extension, so it isn't on the allow-list). The change itself is a legit devcontainer/CI edit, not an algorithm file.

@cclauss — same situation as #15157, which you reopened; could you reopen this one too (I don't have the permission)? If you'd rather avoid the Dockerfile entirely, I can drop that hunk and set the base image purely via devcontainer.json's build.args.VARIANT (which overrides the Dockerfile ARG) — the trade-off is we'd keep the deprecated vscode/devcontainers/python image path and lose the uv install line. Your call.

[algorithms-keeper]

Closing this pull request as invalid

@priya-sundaram-dev, this pull request is being closed as the files submitted contains an invalid extension. This repository only accepts Python algorithms. Please read the Contributing guidelines first.

Invalid files in this pull request: .devcontainer/Dockerfile

[algorithms-keeper]

Closing this pull request as invalid

@priya-sundaram-dev, this pull request is being closed as the files submitted contains an invalid extension. This repository only accepts Python algorithms. Please read the Contributing guidelines first.

Invalid files in this pull request: .devcontainer/Dockerfile

[cclauss]

This is a massive bummer because you created TheAlgorithms/algorithms-keeper#228 (can you add Dockerfile to that PR), but neither @poyea nor I have permission to merge it. We NEED help from @dhruvmanila, @AnupKumarPanwar, or @dynamitechetan to merge that.

In the meantime, is there a way to disable algorithms-keeper on this repo?

Can you please recreate this PR without the changes to the Dockerfile, and then I will make those separately?

In this PR, can we specify free-threaded Python 3.14t instead of 3.14??