Implement flat receipt expense calculation logic

Model the receipt threshold as ExpenseTypeConfig.receiptThresholdNok (double) with a default of 100.0. The isIncomplete flag is the key design decision here: the HLF requirement says 'flagged as incomplete rather than rejected immediately' — this means the calculation layer must not block the result, only annotate it. The BLoC layer will inspect isIncomplete across all line items before enabling the submit button. Keep the three flat receipt subtypes (tollroad, parking, transit ticket) handled by the same calculateFlatReceipt method — use expenseTypeId to determine config lookup key, not a separate method per type.

This avoids the feilkombinasjon problem (user selecting both km and bussbillett) being enforced at the calculation level — that mutual exclusion is enforced at the selection UI layer, not here. Avoid making FlatReceiptResult a subtype of PerKmResult — they are sibling sealed class subtypes of ExpenseLineItem.

Write unit tests using flutter_test covering: (1) amount 99 NOK — receiptRequired false, isIncomplete false, (2) amount exactly 100 NOK — receiptRequired true, isIncomplete depends on hasReceiptAttached, (3) amount 101 NOK without receipt — isIncomplete true, result still returned, (4) amount 101 NOK with receipt — isIncomplete false, (5) amount 0 NOK — returns zero result without exception, (6) org config with custom threshold (e.g., 200 NOK) is respected, (7) requiresManualApproval set to true when config specifies manual routing. Mock ExpenseTypeConfigRepository. Target 100% branch coverage on the threshold and receipt logic paths.