Trying to sync to more official version of tables

[maritsandstad]

This is a first step towards getting official versions of tables and grids into our flow.

[maritsandstad]

@AgentOxygen and @mvertens this is very much work in progress, and needs more help with scientific testing eventually, but I do think it is useful to make this PR so that we can discuss the direction.

I do also think your new scheme in #119 can be related to this as this was actually quite fiddly todo, partially because it was often far from clear where we were pulling data for to run the flow, and definitely we were not doing it in the best ways.

[mvertens]

@maritsandstad - the following issues were raised by Claude:

• The new code isn't tested. 191 lines decide what goes into every submitted file, and nothing checks them directly. It's a function that takes arguments and returns a dictionary, so testing it is easy — worth doing before this becomes the only path.
• Some values quietly fall back to defaults. If a lookup fails, the code picks something and carries on: grid_label becomes "gr", activity_id becomes "CMIP", and so on. Those land in the files. The grid label worries me most, because CMIP7 uses codes like g100 and "gr" may not be valid at all — and a warning buried in a long log won't be noticed.
• Two attributes could come out empty. data_specs_version and Conventions are read straight from the CV with no fallback, so if the new tables don't have them at the top level you get nulls in the output.

[maritsandstad]

@maritsandstad - the following issues were raised by Claude:

• The new code isn't tested. 191 lines decide what goes into every submitted file, and nothing checks them directly. It's a function that takes arguments and returns a dictionary, so testing it is easy — worth doing before this becomes the only path.
• Some values quietly fall back to defaults. If a lookup fails, the code picks something and carries on: grid_label becomes "gr", activity_id becomes "CMIP", and so on. Those land in the files. The grid label worries me most, because CMIP7 uses codes like g100 and "gr" may not be valid at all — and a warning buried in a long log won't be noticed.
• Two attributes could come out empty. data_specs_version and Conventions are read straight from the CV with no fallback, so if the new tables don't have them at the top level you get nulls in the output.

So to Claude, we could have testing for it, but it is not super meaningful testing in my opinion, and what we had before was definitely just a file that hung out...

For the second, that is absolutely on purpose so we can have something functioning also for non-CMIP runs.

The third for now is also a typical Claude wanting belt and suspenders for everything thing. The CV should work, if it doesn't there is no reason to have a fall-back...