fix(datastore): batch insert of command rows fails on Postgres for derived command types

[jordanfelle]

Fixes #227.

Problem

BasicRepository.InsertMany (batch paths for Postgres and SQLite) adds each value with parameters.Add(name, prop.GetValue(model)), so Dapper resolves the type handler from the value's runtime type. CommandModel.Body has a handler registered for the base type Command only, so any derived command fails with The member p0_Body of type ...RefreshAuthorCommand cannot be used as a parameter value. Single Insert binds by the declared property type and works. The bulk author editor hit this through CommandQueueManager.PushMany (worked around per command in #210).

Fix

Register the same CommandConverter handler for every concrete command type (CommandConverter.ConcreteCommandTypes, plus UnknownCommand), so the lookup by runtime type succeeds. CommandModel.Body is the only column found whose handler is registered for a base type; the other handlers (OsPath, Guid, QualityModel, dictionaries, List<int>, ...) are keyed on the exact runtime types stored. After this, PushMany (#210) could go back to a single InsertMany.

Verification

New SQLite-backed BasicRepositoryInsertManyDeclaredTypeFixture: a batch of derived commands is stored and read back as the right type, stores the same value as single Insert, and null / other handler columns still work. The tests fail without the fix with the exact production error (3,023 core tests pass).

Untested on Postgres (none available here): the failing lookup is Dapper's and is independent of the database; the SQLite batch path shares the same parameter-binding code.

• Adds every_concrete_command_type_should_have_the_command_handler_registered, a guard that fails if a future command type is not covered by the reflection-based registration (54 concrete types plus UnknownCommand today; the same pattern TableMapping already uses for IProviderConfig) (3,024 core tests pass).