Pin dependencies

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
@azure/identity (source)	dependencies	pin	^4.0.1 -> 4.4.1
@bufbuild/protobuf (source)	dependencies	pin	^1.10.0 -> 1.10.0
@connectrpc/connect (source)	dependencies	pin	^1.4.0 -> 1.4.0
@connectrpc/connect-fastify (source)	dependencies	pin	^1.4.0 -> 1.4.0
@connectrpc/connect-node (source)	dependencies	pin	^1.4.0 -> 1.4.0
fastify (source)	dependencies	pin	^4.28.1 -> 4.28.1

Add the preset :preserveSemverRanges to your config if you don't want to pin your dependencies.

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[ecraig12345]

@kenotron FYI, I previously updated lage to pin most of its deps for the reasons outlined in the comment below. It seems like probably a good idea to keep that strategy unless you know of some reason it won't work now. (It doesn't appear to be causing dupes for the pinned packages based on the lock file updates.)

lage/renovate.json5

Lines 53 to 64 in 3fb589f

	// lage bundles its dependencies, so any updates should to dependencies should be explicit
	// so that they trigger a new lage version (with proper documentation of included updates).
	// The standard approach of using ^ dependencies and allowing implicit updates via the lock file
	// (which with a published bundle, are guaranteed to affect consumers) makes it very hard to
	// track when an issue was introduced if it's discovered in another repo.
	"rangeStrategy": "pin",
	"matchFileNames": ["packages/**"], // ignore this for docs, scripts, root
	"matchDepTypes": ["dependencies"],
	// lage packages aren't an issue since they're within the repo and the latest version is always used
	"excludePackagePrefixes": ["@lage-run/"],
	// this is a runtime dependency of lage since it publishes binaries
	"excludePackageNames": ["glob-hasher"]