fix(supermarket): honor a profile's supermarket_site in the read commands

[tas50]

The defect

supermarket.New — used only by share — falls back to the profile's supermarket_site. NewAnonymous — used by list, search, show, download, install, and explore — does not.

So a user with a private Supermarket configured publishes to it and reads from the public one, unless they remember to repeat --supermarket-site on every single invocation. supermarket_site is a key this CLI writes itself during config create, validates in config validate, and carries across during chef migration, so it is reasonable to expect it to be honoured.

The split was visible in the help text itself:

share:      "... (default: profile supermarket_site, then https://supermarket.chef.io)"
the other six: "... (default: https://supermarket.chef.io)"

install is the clearest case. It already calls resolveClient and has the profile in hand, then builds the Supermarket half anonymously anyway — so it fetches a public cookbook and uploads it to the user's server when they meant their own.

The fix

resolveSupermarketSite(cmd, siteFlag) resolves flag, then profile, then the public default, reusing the profile-selection rules share already applies (explicit --profile / $CINC_PROFILE / $CHEF_PROFILE, then the conventional [supermarket] section, then [default]). That selection logic is factored out into selectSupermarketProfile and shared, rather than duplicated.

Two properties it deliberately keeps:

• It never triggers the first-run flow. These commands need no credentials, and dropping a user into interactive setup because they ran cinc supermarket download would be much worse than the bug being fixed. It reads the file directly rather than going through loadCredentials.
• It never fails. A missing or unreadable credentials file just means no configured preference, so it returns "" and the caller uses the public default.

Help strings and docs/commands/ are regenerated to match.

Tests

TestSupermarketReadCommandsUseProfileSite drives download, show, search, and list against a recording server named only in the profile. All four fail without the wiring:

--- FAIL: .../download   download never reached the configured Supermarket at http://127.0.0.1:64208; it used the public default
--- FAIL: .../show       ...
--- FAIL: .../search     ...
--- FAIL: .../list       ...
FAIL  github.com/cinc-project/cinc-cli/apps/cinc/cmd  63.743s

That 63 seconds is itself the evidence: the commands were making real calls to supermarket.chef.io. With the fix the same test runs in 0.77s and makes no external call, so the committed suite stays network-free.

Plus unit coverage for the precedence: flag beats profile, [supermarket] beats [default], a profile without the key falls back, and no credentials file at all falls back rather than erroring.

go test ./..., go vet ./..., and gofmt -l . are clean. All supermarket commands are already exempt in the coverage manifest (they need the external service), so it is unchanged.