I have never managed to achieve "clever and efficient" in OM computation algorithms, so I have chosen to embrace "straightforward and comprehensible," which I can.  In this instance, that means I aimed for a simple conversion from binary, where salt represents 0 and fire 1, to base-6, where lead is 0 and gold is 5.  
  
The implementation logic is pretty straightforward, too. I process the input one atom/digit at a time, starting from the largest magnitude, and track its effect on both the units digit and sixes digit of the output, assuming a baseline of 00 (lead-lead)

In the theme of "straightforward and comprehensible," I reached for Ravari's Wheel as a ready-made register.  Changing the units digit is simply a matter of rotating the wheel some number of times (value % 6), and tracking sixes is merely a question of counting how many full rotations the wheel would does--aka "carries" (value / 6).  Yes, basically just counting on my fingers like a kindergartener. Hence the solve title.

The main challenge with this method is keeping track of "carries."  The largest binary digit, 16, always results in 2 carries, and the second largest, 8 always results in 1 carry.  But when you have both together (24), there will be 4 carries, not 3!  Unlike for units, it is not enough to handle each digit in isolation.

I resolve the carries logic with a mess of wanding conditionals on the left.  Each of the fire binary digits (except the smallest) generates some amount of quicksilver, which is used to conditionally project lead based on what previous digits were also fire.  Attach this projected metal to whatever spoke of Ravari's Wheel we rotated to, and Bob's your uncle!

However, I did make one departure from "straightforward."  A fully-correct carry calculation was annoyingly complicated, so I leveraged the fact that we don't need all 36 possible metal cases.  Hence, the units digit of my encoding is perfectly normal for a base-6 conversion, but the sixes digit has oddities in the top half.  It produces copper only in 4 cases, silver in 4, gold in 4, and gold-plus-one in 2.  But gold-plus one, in projection, is still gold, so it all works out!

##################
TO HAXTON: feel free to skip reading this parenthetical.  It contains the underlying logic of my carries, which shows why I get too many at the top end.  Just in case you or anyone is curious.

digit A: 16 --> 2 carries
digit B: 8  --> 1, +1 if A
digit C: 4  --> 0, +1 if A||B
digit D: 2  --> 0, +1 if A||C
digit E: 1  --> 0

So ABCD (30) yields 6 carries, for example, when it should actually be 5.  And BCD (14) yields 3, when it should actually be 2.  And so on.

The *proper* way to do it would have been this:

digit A: 16 --> 2 carries
digit B: 8  --> 1, +1 if A
digit C: 4  --> 0, +1 if A⊕B 
digit D: 2  --> 0, +1 if (A⊕C) && !B
digit E: 1  --> 0

The XOR and NOT conditions were much too annoying to contemplate.
##################

Otherwise, all my work was on standard Sum optimization.  I ran this algorithm as fast as 114c and as cheap as 400g, but this machine here struck the best balance.

I did muse about how fast a triplex-fire register could go.   In this Ravari's Wheel machine, I need 6c to evaluate each digit (grab-pivot-pivot-rotate-drop-return).  By switching to a salt=1 encoding for units, I could reduce that to 4c, at noticeable additional expense.  Meanwhile, triplex-fire registers can capture all of that logic in 2c, for a lower bound of ~75c overall.  So the only competitive advantage I'm gaining with this method is the simplicity of reading out from the register at the end, which can be managed entirely with existing machinery.  Which is hardly even worth mentioning, since I also need to either spend significantly on waste removal or accept an even more costly waste chain.

But you know what?  I don't care.  I didn't feel like implementing a fire register. The setup and movement encoding I could visualize well enough, as it isn't much different from the wheel, but figuring out how to read the result felt super annoying. I'm content to wait and see what other folks do with it.  Amaze me, wizards!!!

************

Last, and certainly not least: thank you so very much, Haxton, for running a great event and being such an excellent stream host!