Bug - JMESPath `*` vs `[*]` semantics

Per the JMESPath specification, `*` (hash wildcard) and `[*]` (list wildcard) are **never interchangeable**:

| Expression | On object | On array | On wrong type |
|---|---|---|---|
| `*` | Returns values as list | **`null`** | `null` |
| `[*]` | **`null`** | Returns elements as list | `null` |

### AST structure in jmespath 0.5.0

The two operators produce distinct AST nodes:
- `*` → `Projection { lhs: ObjectValues(Identity), rhs }` → dispatched to `visit_wildcard_projection`
- `[*]` → `Projection { lhs: Identity, rhs }` → dispatched to `visit_projection`

### `.[*]` is broken in jmespath 0.5.0

The primary example in this issue (`*.[*] | [?status == 'active']`) uses `.[*]` (dotted list wildcard). This construct is **broken at the parser level** in jmespath 0.5.0:

**Expected AST for `.[*]`:** `Projection { lhs: Identity, rhs: Identity }` (same as standalone `[*]`)

**Actual AST:** `MultiList([Projection { lhs: ObjectValues(Identity), rhs: Identity }])` — a multi-select list wrapping a **hash wildcard**, not a list wildcard.

**Runtime verification:**

```
* on {"a":[1,2],"b":[3,4]} => [[1,2],[3,4]] ✓
[*] on {"a":[1,2],"b":[3,4]} => null ✓ (spec: [*] on object → null)
*.[*] on {"a":[1,2],"b":[3,4]} => [[null],[null]] ✗ (expected [[1,2],[3,4]])
[*] on [[1,2],[3,4]] => [[1,2],[3,4]] ✓
[*].[*] on [[1,2],[3,4]] => [[null],[null]] ✗ (expected [[1,2],[3,4]])
```

The `.[*]` construct produces `null` for each projected value because the parser represents it as a hash wildcard (`*`) applied to arrays, which returns `null` per the JMESPath spec.