hud/server: make apiserver config registration atomic

[prajwalshah19]

Fixes #6814.

addToAPIServerConfig and removeFromAPIServerConfig read the shared config under a read lock, released it, mutated an in-memory copy, and later wrote the full snapshot back under a separate write lock. The write lock serializes writers but doesn't protect the whole transaction, so two Tilt processes can read the same base snapshot and the later writer discards the earlier one's registration or removal.

The result is a CLI command failing with No tilt apiserver found: tilt-<port> against a server that is still running and healthy — the entry was simply dropped from the config by an unrelated Tilt process.

This holds the exclusive lock across the entire read-modify-write in both functions, so concurrent processes serialize on the full transaction. modifyConfig was only used by these two callers and is inlined into them; ValidateAPIServerName now runs before the read, so an invalid name no longer takes the lock or touches the file.

No deadlock risk from the nested clientcmd.ModifyConfig call: internal/filelock's init() sets clientcmd.UseModifyConfigLock = false, so ModifyConfig doesn't take a lock of its own.

Testing

TestConcurrentAPIServerConfigUpdates registers and then deregisters 8 controllers concurrently against one config file. It fails on master — an entry survives after every removal, the lost-update — and passes with the fix. Clean under -race -count=10.

Also run: make shorttest (full suite; the only failures are the pre-existing TestKustomizeFlags/TestKustomizeBin, which fail identically on unmodified master because kustomize isn't on my PATH), go vet, goimports -local github.com/tilt-dev, and golangci-lint (0 issues).

Notes for reviewers

• Mixed versions still race. The lock is advisory and only helps processes running this code, so an older tilt binary alongside a fixed one can still clobber the config.
• Slightly longer exclusive hold. The read moves from a shared lock to the exclusive one, so two concurrent startups serialize where they previously read in parallel. The file is small, so this should be immaterial — flagging it as a real behavior change.
• I verified on macOS only; Windows semantics look equivalent (LockFileEx exclusive per handle) but I haven't run it there.