То есть вопрос тупо в том, как уменьшить сумму Х?

Исправление уже сделано, так как обычно доработки оплачивались пост-фактум.
Вопрос лишь в том, как это интерпретировать.

Формально говоря, это баг, то есть у исполнителя была возможность предусмотреть такую ситуацию с самого начала. С другой стороны, это могло в те самые полтора раза увеличить исходную стоимость 😊

А был ли выбор изначально? Или сначала сделали, а потом подумали?

Если было прописано изначально - проблемы исполнителя. Если по ходу дела выяснилось - доплатите по часам или по ЧТЗ.

Вопрос скорее стратегический - как вести себя в подобных ситуациях каждой из сторон.
Стратегия 1:  заказчик поставляет комплект тестов, все что не попало под тесты - это не баг, а развитие за отдельные деньги.
Стратегия 2:  любые баги правятся бесплатно ограниченный период времени.
и т.д.

В Конкретном случае они безусловно разрулят ситуацию, так как в конфликте ни одна их сторон не заинтересована.

В стратегии 2 есть проблема - что считать багом а что нет

вопрос в том, насколько это можно было предусмотреть, если, например, не хватало индексов в БД и на малом объеме все приемлемо работало, но была возможность посмотреть как бы это работало на большом объеме - это один сценарий, если архитектура выбиралась под конкретные требования и они изменились, это уже другой сценарий. В любом случае это чей-то факап, либо аналитика заказчика, либо QA исполнителя, либо процесса приёмки, в любом случае думаю тут нет универсального способа разрешения  конфликта.

Тестовый пример, на котором алгоритм дает неверный результат.

Забили в базу миллион документов, запрос сдох по тайм-ауту - чья проблема? То же, но запрос делается 25 секунд - чья проблема?

Забыли индекс - это чья беда? База на продакшене работала с конфигом по дефолту и на HDD - а это чья?

Я приведу такую аналогию: надо написать функцию излечения (ближайшего целого) корня целого числа.
Она работает и все довольны. А потом ей на вход подают число, которое не помещается в int и всё сломалось.
Формально в задании не сказано, что за диапазон должен поддерживаться. И тестов не было.

Кто тут прав?

BA, кто писал спеку. Кто это в вашем случае?

Точнее, на чьей он стороне?

Предусмотреть было можно.
На практике проблема затрагивала 1 запись из 800-900 тысяч и как-то найти ее было бы на дорого (я полагаю).

А запись с такими значениями атрибутов вообще валидна? Если да - почему это не отражено в спеке? Если нет - что она делает в базе?

Предусмотреть можно всё, но тогда ценник будет от 10Х до 1000Х. См "авионика"

Ситуация хитрая, спека написана третьей стороной. Можно считать это стандарт или что-то типа RFC.
То есть задача выглядит так "вот спека, вот примеры которые у нас есть, нам нужно сделать вот это".

Делаем по спеке, валидируем на имеющихся кейсах, в сложных случаях уточняем у заказчика и покрываем дополнительными кейсами.

Вот ровно это я ему и говорю. Если такое предусматривать заранее, то это будет по стоимости написанием софта для АЭС.

При появлении претензий курим спеку. Если в спеке есть - правит исполнитель за свой счёт. Если нет - делаем по T&M или пишем и оцениваем ЧТЗ.