In a venv installed with --suffix, an injected package is renamed each time its record is rewritten. After pipx install pycowsay --suffix @1 and pipx inject pycowsay@1 black --with-suffix, one pipx upgrade --include-injected pycowsay@1 turns the key black into black@1 (a second run gives black@1@1). Then pipx uninject pycowsay@1 black reports "black is not in the pycowsay@1 venv", pipx pin adds a second black@1 entry, and pipx reinstall pycowsay@1 fails with Invalid requirement: 'black @ 1'.

PipxMetadata.from_dict rebuilt the injected_packages keys as f"{name}{suffix}", while the writer (Venv.update_package_metadata) and docs/reference/metadata.rst key them by package name, with suffix as a separate field. Every read-modify-write therefore appended the suffix again. This keeps the bare name as the key, stops run_post_install_actions from rebinding the key to the display name, and lets uninject accept pkg@1 as before by matching the record's own suffix.

Visible change: pipx list --include-injected now shows black instead of black@1 under a suffixed venv. Metadata already corrupted on disk is not repaired.

Test: pytest tests/test_upgrade.py -k suffix_keeps fails on main (uninject exits 1 after the upgrade) and passes here. A broader run of upgrade, pin, uninject, inject, list, reinstall, install and related modules passed, except test_install_fetch_missing_python_invalid[3.1-fetch-python-missing], which fails the same way on main. ruff check/format --check and ty are clean on the changed files; pre-commit run --all-files was not run.

• ran the linter to address style issues (pre-commit run --all-files)
• wrote descriptive pull request text
• ensured there are test(s) validating the fix
• added news fragment in changelog.d/ folder (choose a type: feature, bugfix, doc, removal, or misc)
• updated/extended the documentation