Bug: Client crashes with AssertError 'The DB result must have 20 columns' during consistency check

### Describe the bug

The client can crash with a hard `AssertError` when a SQLite query used during database consistency checking returns a result set whose column count differs from the expected 20 columns.

The `assert(result.front.length == 20, "The DB result must have 20 columns")` check in `src/itemdb.d` inside `ItemDB.buildItem` assumes every query feeding it returns exactly 20 columns. In practice, the D SQLite binding's `Statement.Result.front` can report a different value count — for example 19 — when a `WHERE` condition on a `NULL` column is expressed with `=` instead of `IS NULL` (the library binds values cumulatively across the result set, so `front.length` is not always the row width). When this happens, the client aborts mid-sync:

```
core.exception.AssertError@src/itemdb.d(849): The DB result must have 20 columns
```

The crash repeats every monitor cycle (~90 seconds) and the client cannot complete synchronisation until the database is rebuilt (`--resync`), losing the local cache.

### Operating System Details

* Linux mektop 7.2.4-3-cachyos #1 SMP PREEMPT_DYNAMIC Fri, 11 Sep 2026 07:41:12 +0000 x86_64 GNU/Linux
* CachyOS (rolling, Arch-based)

### Client Installation Method

- [x] From Source

### OneDrive Account Type

- [x] Personal

### Application Version

* v2.5.11 (also reproduced on current master @ 6965af2; the `assert` is unchanged in `src/itemdb.d`)

### Configuration

Systemd service `onedrive-mekwall.service`, default config, ~137 000 items in the local database.

### Relevant Log Output / Trace

```
Application output that is doing whatever | illustration of issue
```

```
core.exception.AssertError@src/itemdb.d(869): The DB result must have 20 columns
----------------
???:? onThrown [0x55f??]
???:? _d_assert_msg [0x55f??]
???:? onedrive.onedrive.itemDB.buildItem [0x55f??]
???:? onedrive.onedrive.itemDB.?? [0x55f??]
```

Service log shows the assert firing repeatedly and systemd `Restart=on-failure` looping the client.

### Additional context

The fix that has been verified locally over 17+ minutes of continuous monitoring (2 full sync cycles, 0 crashes, 33 recovered column-count mismatches logged) replaces the hard assert with a warn-and-skip guard and adds `ItemType.none` guards at every `buildItem` consumer. A pull request with this change will be linked to this issue.