cli: collapse --tag provided/value signals into one in browsers update

[bmsaadat]

Summary

tagsFromFlag now reports whether the --tag flag was provided (independent of whether its values parsed), so runBrowsersUpdate no longer rebuilds that signal via cmd.Flags().Changed("tag") — BrowsersUpdateInput.SetTags is renamed to TagsProvided and sourced from the helper, with the three other call sites discarding the new bool. This is a behavior-preserving structural cleanup (non-blocking follow-up to #184) that leaves the --name/--clear-name side untouched, since it has no equivalent redundancy. Two helper tests were added to pin the newly-distinguished "absent" vs. "provided-but-all-malformed" states.

Test plan

• go build ./..., go vet ./cmd/, gofmt -l clean
• go test ./... green (incl. TestBrowsersUpdate_*, TestTagsFromFlag_*, TestParseKeyValueSpecs)
• CLI smoke: --tag foo → "No valid --tag KEY=VALUE pairs provided"; --tag foo --clear-tags → "Cannot specify both --tag and --clear-tags"

🤖 Generated with Claude Code

---

Note

Low Risk
CLI-only flag parsing refactor with regression tests; intended to preserve browsers update validation behavior.

Overview
tagsFromFlag now returns parsed tags plus a provided bool from pflag’s Changed, so an empty --tag= still counts as the user passing --tag (not a silent no-op).

browsers update wires that bool into BrowsersUpdateInput.TagsProvided (replacing SetTags and duplicate Changed("tag") in the runner). Validation for conflicting --clear-tags, all-malformed tags, and lone empty --tag still keys off “flag was provided,” not only a non-empty map.

List/create/acquire call sites adopt the new two-value return and ignore provided. Tests add tagsCmdWithArgs and cases for absent flag, all-malformed, and empty --tag=.

^{Reviewed by Cursor Bugbot for commit 282203a. Bugbot is set up for automated code reviews on this repo. Configure here.}

[firetiger-agent]

Firetiger deploy monitoring skipped

This PR didn't match the auto-monitor filter configured on your GitHub connection:

PRs in the kernel, infra, hypeman, and hypeship repos. kernel is a ~mono repo with many logical services underneath, ensure to focus on the implicated service for the PR

Reason: PR is in an unspecified repo; while it mentions CLI changes that could relate to kernel services, the repo name is not confirmed to be one of the four monitored repos (kernel, infra, hypeman, hypeship).

To monitor this PR anyway, reply with @firetiger monitor this.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 49f26e5. Configure here.}