[clangd][HLSL]Code Completion for HLSL Vector Swizzle Members

## Expected Behaviour

Typing `v.` on a `float3` should suggest `x`, `y`, `z`, `r`, `g`, `b`. Typing `v.x` should suggest only `x`, `y`, `z` (locking to the xyzw set). Typing `v.xr` should suggest nothing (mixing sets is semantically invalid). Typing `v.xyzw` should suggest nothing (4-component limit reached).

## Observed behavior
Typing `v.` produced no suggestions.

## Reproduction
```hlsl
[numthreads(1,1,1)]
void main() {
float3 v = float3(1.0, 2.0, 3.0);
float a = v.
}

```

## Root cause

`CodeCompleteMemberReferenceExpr` handled `RecordDecl` members but had no case for `ExtVectorType`. The already-typed prefix (e.g. `"x"` when typing `v.x`) was available via `getCodeCompletionFilter()` but not used, so semantically invalid combinations like `v.xr` were not filtered.

## Proposed fix
Add an `ExtVectorType` branch in `DoCompletion` inside `CodeCompleteMemberReferenceExpr`. `AddHLSLVectorSwizzleCompletions` reads `getCodeCompletionFilter()` and enforces three rules:
(1) no mixing xyzw/rgba sets: detected from filter characters;
(2) max 4 components;
(3) only valid components for the vector size.

Start in DoCompletion inside CodeCompleteMemberReferenceExpr, where RecordDecl members are handled and the ExtVectorType case is missing. Review AddHLSLVectorSwizzleCompletions and getCodeCompletionFilter(); done means v. suggests valid swizzles, locks to one naming set, rejects mixed or over-four-component prefixes, and limits components to the vector size.

Written by the indexing model from the issue text.