Entity states are only added to the DB when they change. This makes sense for most entities since they change with some frequency and it limits the size of the DB. However, for entities that change very rarely it means that the state history disappears after the purge interval if it hasn’t changed. This is really not true since the entity has a history value, namely its current value. This impacts things like the History Graph card in the UI which suddenly fails to find any history and stops displaying the flat line - which changes what the user sees. Ideally, a purge would not delete the only entry for an entity so that the history would remain correct. This may be hard to achieve or have other undesirable side effects. In that case, a middle position that should be relatively easy to add would be a recorder service call to force an entity history entry. Then if a user has such a slow changing entity, they could have an automation that periodically (more often that the purge setting) would force a recorder state update for that entity, thus keeping it fresh. I would envision it similar to the recorder.purge_entity service in format.
You could do this today if you want. Just create a rest command that does POST /api/states/<entity id> (see REST API doc for more info on this API). Set it up so when you provide an entity ID it reposts its current state but with a dummy attribute set to the current timestamp. This counts as a state change and so it will be recorded in history but there’s no actual effect from your perspective since all the meaningful fields didn’t change.
Also I feel like personally I’d recommend rephrasing your feature request a bit. It sounds like what you really want is for recorder to never purge history entries which are still current. So even if this entry is a week old and my purge time is set to one hour, don’t purge it if its the latest state change event for an entity. This way there’s always at least one.
I could get behind a feature request like that because that makes sense to me. There’s some challenges of course (like how does recorder determine when to purge all history entities because the entity no longer exists and when to leave exactly one because its still the current state of an existing entity). But it makes sense overall.
I don’t really like the idea of generating fake history events on a schedule when nothing actually changed personally, that bothers me. And besides the history graphs already fill to the left so you really don’t need to generate history events on a schedule, you just need to always have at least one.
Also final note - you should vote for your own feature request 
I agree entirely with your comment. The request itself does describe not purging active entries but then for some reason I got wrapped around the idea that doing this might be too difficult and do jumped to a possible workaround. The real issue is that a valid history element is being deleted with the result that history that should be present is not. So I edited the title to reflect this.
Didn’t think about using the REST interface for this although that does seem a bit awkward since you’re sort of talking to yourself via an external interface if you do it from an automation. But good to know about that approach. Thanks.
And yea - forgot to vote for it - duh! 70 year old brain at work. 