I just checked the WFA database, and unfortunately the export policy (id) is not a column within the qtree table.
You can create custom commands (Powershell Code) to figure it out and add/remove servers from an export policy.
Another alternative, is to have a 1-to-1 relationship of qtrees to export policies. You can then call the export policy the same name as the junction path to the qtree. (Export policies can contain slashes) . Then you can do a lookup on the export-policy based on the qtree path.
Even if you are going into a "brown-field" deployment to do automation, you can get all the qtrees over to new export-policies or renamed export policies.
I did this back in Ontap 8.2 days, so please test if you want to roll with this idea. 😄
If you already have a one-to-one mapping of export-policy to qtree export, you can do an "export-policy rename" command on the Ontap Cluster without any impact.
If you don't already have a one-to-one mapping, (IE 1 policy to many exports), you can copy the export-policy through the "export-policy copy" command. This will create duplicate export-policies, that you can then modify the qtree export (qtree modify) to be that copied version with the new name.
This idea has some leg work obviously, but gets to the end goal. This also allows you to use the out of the box approach mentioned previously.
To be honest, I'm not sure of the official channel of making a feature enhancement, but this channel is a spot I throw my suggestions now and again. Your suggestion of getting the qtree's export-policy assigned in the DB is a good suggestion, and probably wouldn't be that hard. However, WFA is dependent on the data in OCUM. Thus, if OCUM isn't collecting it, they would need to do an enhancement there as well.