enhance: resolve query views using collection vchannels

[sunby]

Resolve query-view shard fanout from Proxy collection metadata instead of publishing shard/replica entries through assignment discovery. Port chyezh#85: Phase 1 addresses the primary StreamingNode with an UnknownReplicaID, and Phase 2 uses the real replica ID returned in the query plan.

Adapt this branch's automatic-loading entrypoint by keeping CollectionReadiness on the Proxy query-client wrapper and implementing it through QueryCoord ShowLoadCollections/QueryServiceAvailable. This changes the readiness criterion: it no longer matches every expected vchannel against a local assignment snapshot. Each DQL request with automatic loading enabled adds a status RPC; a pending load is polled every 10 ms. The branch's PChannels list optimization and query-phase timing logs are retained.

issue: milvus-io#40451
Source PR: chyezh#85
Source commit: chyezh@e98b244

Validation:

• git diff --check and run_clang_format.sh passed. Formatter changes outside this PR were discarded.
• make lint-fix ran gofumpt/gci, then stopped in golangci-lint type checking because the existing C.Analyze call passes four arguments while the local native header accepts three; the full lint target did not pass.
• Query-client/resolver and assignment package tests passed with -tags dynamic,test -gcflags="all=-N -l" -count=1.
• Readiness tests passed using the production source and lightweight Proxy/coord fixtures, covering unavailable/released collections, cancellation, malformed responses, and error propagation. These are not full Proxy integration tests.
• Full Proxy, distributed Proxy, SN view/adaptor, and channel/discovery tests could not compile against the local native artifacts: missing segcore symbols and incompatible Analyze / loon_properties_inject_external_spec signatures.

Review limitations:

• The adapter only checks that expectedVChannels is nonempty, then trusts QueryCoord's readiness flag, which is calculated from registered shard views. Equivalence to the former complete-routing barrier and its latency/load impact remain unverified end to end.
• The upstream change renumbers the assignment protobuf secondary_channels field from 4 to 3. Mixed-version compatibility and routing with multiple replicas per vchannel have not been validated.