Release v1.4.1

Fixed

• A silo referencing both Cratis.Orleans and Cratis.Chronicle could not start, because both ship a JobsManager grain and Orleans gave them the same derived grain type name (#16)

---

Orleans derives a grain type name from the class name alone, ignoring the namespace, so Cratis.Orleans.Jobs.JobsManager and Cratis.Chronicle.Jobs.JobsManager both claimed jobsmanager:

System.InvalidOperationException: An entry with the key jobsmanager is already present.
Existing:      "full-type-name": "Cratis.Chronicle.Jobs.JobsManager", ... "Cratis.Chronicle.Core"
Trying to add: "full-type-name": "Cratis.Orleans.Jobs.JobsManager",  ... "Cratis.Orleans"
Consider using the [GrainType("name")] attribute to give these classes unique names.

Neither carried [GrainType], so both fell back to the derived name. An application cannot work around this — it references neither class directly and cannot rename either — and nothing in a normal build or spec run exercises silo start, so it surfaces only at deployment.

Naming ours is the side that is safe to change: Chronicle's grain identity is already in use by every existing store.

The accompanying spec fails without the attribute, so the name cannot quietly revert to the derived one. JobsManager was the only grain class name shared between the two libraries.