If the codes are mapped to the ancestor, then you will only be able to find the records if you make a concept set with the ancestor concept ID (you could include descendants, but the source codes only map over to the ancestor). There’s not a problem here, per se, unless you want to distinguish the class 1 codes from other classes (the mapping is making the class 1s look like a generic ‘Partial edentulism’.
If you make a concept set for the specific class 1 concepts, none of the records mapped from ICD9s will be found (because they map to the generic ancestor).
You will find that patient records that mix ICD9 and ICD10s will show that for the ICD9 codes they would map up to the generic ancestor ‘Partial edentulism’ while the ICD10 records will map over to the more specific classes. That may impact your analysis (if you care about the different classes).
I do wonder why the ICD9s (which do seem to have the granularity of classes) weren’t mapped to the same level in SNOMED, but that loss of precision exists in the ICD9 mappings.
As far as Achilles: those reports based off the row-level coding of the condition_occurrence records: the people coded with ICD9 will contribute to the counts for the ancestor concept, while the ICD10s will contribute to counts for the class-specific descendants.