This is a hacky patch for a problem that runs more deeply: the use of
floating-point for Mana calculations, along with the associated rounding
errors.
Consider the following example:
```typescript
const balance = 1000
const bet = 5.6e-14
const newBalance = balance - bet
if (newBalance == balance) {
alert(`I placed a bet of ${bet} without changing my balance.`)
}
```
This will actually print a message, because floating-point numbers can
only represent so many digits, and thus we get 1000.0 rather than
999.99999999999994.
This is a purely theoretical attack at this point; nobody could create
enough pico-bets to actually affect their balance using this technique.
However, I believe is worth ensuring a minimum bet amount, and might
prevent other problems such as the UI showing messages like "User Foo
bought M0 of YES", which could confuse users.
For a more definite solution, we would probably need to change some
computation to integers, where addition is always commutative and
value-preserving. This is similar to what most financial software does
(e.g., Bitcoin uses 1 Satoshi = 0.00000001 BTC as their unit).
* Set common package.json sideEffects: false
* Configure SWC to modularize lodash imports
* Import specific lodash functions instead of _
* Add an eslint rule to avoid full lodash import
* Fix ultra embarrassing bug not restricting CORS origins
* Put CORS origin regexps in common
* Static types so I don't muck it up again
* Fixup CORS regex to be more strict
* Fix sloppy imports to actually work
* Remove needless wrappers from API requests and responses
* Return real HTTP status codes instead of status field
* More robustly handle API errors
* Fix broken error handling in NumericResolutionPanel warmup
* Rename `lib/firebase/api-call` -> `lib/firebase/fn-call`
This relieves ambiguity now that we will be using our actual
public API in the client.
* Rewrite client API calls to createContract, placeBet
* Tiny fixup for client market creation code
