feat(auth): add isolated auth instances

[shangguanxuan633-lab]

What changed

• Add opt-in Auth Instances as isolated login-state storage locations, selected with dws auth list and dws auth use.
• Add dws auth login --new-instance [alias] to create a new storage location and log in without affecting another instance.
• Keep organization/profile switching separate from Auth Instance switching; an instance may contain any user and multiple organizations.
• Scope auth reset, runtime token lookup, profile state, and audit actor cache to the selected instance.
• Serialize mutations to the same instance with process and operating-system file locks, while allowing different instances to proceed in parallel.
• Keep Registry updates under a separate short-lived lock and fail closed if the selected store changes during command initialization.

Compatibility

• The feature is strictly opt-in. Before the first explicit new instance, DWS does not create a Registry, migrate credentials, change the Keychain service, or alter existing login/reset behavior.
• The existing login state becomes the default compatibility instance only when isolation is explicitly enabled.
• After opt-in, reset affects only the current instance, including default, and never clears another instance or shared app configuration.

Why

Multiple DWS processes need independently selectable login-state locations without redefining identity around account or organization. The implementation therefore isolates the storage coordinate itself and uses generated instance IDs only as stable storage keys.

Validation

• go test -count=1 ./...
• go test -race -count=1 ./internal/auth
• focused app Auth Instance/reset/root-switch race tests
• cross-process lock scenarios repeated 10 times
• go vet ./internal/auth ./internal/app ./internal/keychain
• Linux amd64 and Windows amd64 cross-compilation
• git diff --check and gofmt verification

No P0/P1/P2 blocking findings remain after the final scope and concurrency review.

Follow-up coverage

The OS-lock holder is exercised in a real helper process. Fully end-to-end two-CLI-process auth use and concurrent first-Commit scenarios, plus runtime LockFileEx contention on a Windows runner, can be added as non-blocking coverage follow-ups.