I do own a Linkind keypad. It is not a CentraLite one but the whole logic around any keypad should be the same, disregarding the manufacturer.
The keypad is a peripheral device. It is as dumb as it can be, because it has no other task just to report according the commands which it receives, the brain is always the central unit of the alarm.
Communication should be like this.
Wake up, reports wake up. In return central send current state, keypad shows current state.
Enter action and code on keypad, then send it to central. Central reacts on the information and sends keypad what to show.
The likelyhood that the keypad would store alarm state is zero, because the central unit has the alarm state. And that can be changed in many other ways, but the keypad. Like triggered alarm, or disarm with app, etc. The keypad is a sleeping end device, ot might wakes up every hour to report in that it is still there, but generally it communicates with the central unit when it wakes up.
That is the reason, why the keypad does bot function as an alarm panel with Z2M. The functionality of an alarm is not included.
Have a look at this Blueprint to get understanding of the logic: Zigbee2MQTT - Sync Keypad and Alarm Control Panel States
ZHA does create an alarm panel device as I remember, which is quite confusing as alarm control functionality is not provided behind that.
Z2M does not provide the alarm panel, you have to interact with the keypad to make it work, hence the necessity of the Blueprint, and it solves everything.
The difference between the -D or -X should be what color and logo is printed on the device for the convenience of the client mobile company.