Maybe not often advisable, but in some cases SQL on the database can help:
INSERT INTO "PUBLIC"."audittrail$audittrailsuperclass" ("id") SELECT a."id" AS id FROM "PUBLIC"."test$testentity" AS a WHERE a."id" NOT IN (SELECT b."id" FROM "PUBLIC"."audittrail$audittrailsuperclass" AS b)
Where the syntax for table and column names is database dependent and test$testentity is your entity A.
I have not used the Audit module so am making a guess here. Does it work properly if you create a new entry in form A? I suspect it does.
The changes you made to make 'A' a specialization of the Audit-Trail-SuperClass means that the old records are incomplete as they do not have a corresponding entry in the Audit-Trail entity. As far as I know there is no way to correct this for existing data. You should delete the existing entries (if it allows you to) and recreate them.
If it will not allow them to be deleted, you could undo the changes in the Modeler, delete the data, make the changes again, then recreate the data records.
There is an alternative. Making any form a specialization of the Audit-Trail-SuperClass effectively adds the fields and microflows from this entity to all forms that are specializations of it. In other words, all the fields and workflow from the 'parent entity' are shared by all the 'child entities'. Instead of this sharing, you could create copies of these fields on your entity A, and recreate the shared microflows for your individual entity.
Changes such as adding a 'parent' specialization are best done early in your project development, as once there is data present it may cause these sort of problems. For existing projects you are better copying the fields and workflow to individual entities.
Hope this helps