fix: enable incoming onchain request swipe

[ovitrif]

Fixes#1218

This PR persists successful amount validation for incoming on-chain Paykit Payment Requests, enabling the confirmation swipe only after the existing request validation and affordability checks pass.

Description

• Marks a valid, affordable incoming on-chain request amount as input-valid immediately before opening Send Confirm.
• Preserves the resolved endpoint, fixed request amount, private contact context, and existing acceptance ordering.
• Keeps invalid and unaffordable incoming requests blocked.
• Adds focused regression coverage and one user-facing changelog fragment.

Preview

QA Notes

Manual Tests

• 1. Pubky marketplace → open a valid incoming on-chain Payment Request: Send Confirm showed the seller, resolved endpoint, exactly 15,000 sats, and an enabled swipe on the exact PR head using a fresh arm64 regtest emulator.
• 2. Send Confirm → swipe to accept: the request broadcast exactly once as the sole mempool transaction with the exact 15,000-sat invoice output, confirmed after one regtest block, reached Paykit confirmed/1, completed Locks, and returned HTTP 200 for the guarded resource.
• 3. Invalid or unaffordable incoming on-chain Payment Request → open request: confirmation remains blocked.

Automated Checks

• AppViewModelSendFlowTest.kt: covers the payable resolved on-chain state, fixed request amount, endpoint, private contact context, and unaffordable block.
• just compile: passes.
• just test: passes all 2,267 tests.
• just lint: passes with existing baseline findings outside this change.
• ./gradlew assembleDevDebug: passes.
• Dev APK launch smoke on an isolated sdk_gphone64_arm64 regtest emulator: passes with MainActivity resumed and no fatal or ANR logs.

[greptile-apps]

Greptile Summary

This PR enables confirmation for validated, affordable incoming on-chain Paykit payment requests.

• Persists successful amount validation before opening Send Confirm.
• Adds regression coverage for payable and unaffordable incoming on-chain requests.
• Adds a user-facing changelog fragment.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/viewmodels/AppViewModel.kt	Marks the fixed incoming-request amount valid only after the existing validation and affordability checks succeed.
app/src/test/java/to/bitkit/viewmodels/AppViewModelSendFlowTest.kt	Adds focused coverage for successful on-chain confirmation state and rejection of an unaffordable request.
changelog.d/next/1221.fixed.md	Documents that affordable incoming on-chain payment requests can now be confirmed.

_{Reviews (3): Last reviewed commit: "fix: enable onchain request swipe (#1218..." | Re-trigger Greptile}

[ovitrif]

I am closing this PR as superseded by #1178. I created it from the live disabled-swipe defect observed on the then-current master; it supplied a one-line fix, focused regression coverage, and successful marketplace end-to-end evidence. The then-open #1178 already contained the production-equivalent fix e041150 and later merged it, together with positive regression 10ff0df, into master at 9698dea. My initial overlap check did not catch the matching change inside that open PR. This PR therefore no longer has an independent product deliverable, and retaining a conflicting branch only for incremental negative coverage is not warranted. No product behavior or validation evidence is lost.

[ovitrif]

Re-closing after task automation reopened this PR while producing a local APK. The supersession decision above remains unchanged: merged #1178 owns the production fix and regression coverage, so this PR stays closed without merge.

[ovitrif]

Fixes#1218

This PR persists successful amount validation for incoming on-chain Paykit Payment Requests, enabling the confirmation swipe only after the existing request validation and affordability checks pass.

Description

• Marks a valid, affordable incoming on-chain request amount as input-valid immediately before opening Send Confirm.
• Preserves the resolved endpoint, fixed request amount, private contact context, and existing acceptance ordering.
• Keeps invalid and unaffordable incoming requests blocked.
• Adds focused regression coverage and one user-facing changelog fragment.

Preview

QA Notes

Manual Tests

• 1. Pubky marketplace → open a valid incoming on-chain Payment Request: Send Confirm showed the seller, resolved endpoint, exactly 15,000 sats, and an enabled swipe on the exact PR head using a fresh arm64 regtest emulator.
• 2. Send Confirm → swipe to accept: the request broadcast exactly once as the sole mempool transaction with the exact 15,000-sat invoice output, confirmed after one regtest block, reached Paykit confirmed/1, completed Locks, and returned HTTP 200 for the guarded resource.
• 3. Invalid or unaffordable incoming on-chain Payment Request → open request: confirmation remains blocked.

Automated Checks

• AppViewModelSendFlowTest.kt: covers the payable resolved on-chain state, fixed request amount, endpoint, private contact context, and unaffordable block.
• just compile: passes.
• just test: passes all 2,267 tests.
• just lint: passes with existing baseline findings outside this change.
• ./gradlew assembleDevDebug: passes.
• Dev APK launch smoke on an isolated sdk_gphone64_arm64 regtest emulator: passes with MainActivity resumed and no fatal or ANR logs.

[greptile-apps]

Greptile Summary

This PR enables confirmation for validated, affordable incoming on-chain Paykit payment requests.

• Persists successful amount validation before opening Send Confirm.
• Adds regression coverage for payable and unaffordable incoming on-chain requests.
• Adds a user-facing changelog fragment.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/viewmodels/AppViewModel.kt	Marks the fixed incoming-request amount valid only after the existing validation and affordability checks succeed.
app/src/test/java/to/bitkit/viewmodels/AppViewModelSendFlowTest.kt	Adds focused coverage for successful on-chain confirmation state and rejection of an unaffordable request.
changelog.d/next/1221.fixed.md	Documents that affordable incoming on-chain payment requests can now be confirmed.

_{Reviews (3): Last reviewed commit: "fix: enable onchain request swipe (#1218..." | Re-trigger Greptile}

[ovitrif]

I am closing this PR as superseded by #1178. I created it from the live disabled-swipe defect observed on the then-current master; it supplied a one-line fix, focused regression coverage, and successful marketplace end-to-end evidence. The then-open #1178 already contained the production-equivalent fix e041150 and later merged it, together with positive regression 10ff0df, into master at 9698dea. My initial overlap check did not catch the matching change inside that open PR. This PR therefore no longer has an independent product deliverable, and retaining a conflicting branch only for incremental negative coverage is not warranted. No product behavior or validation evidence is lost.

[ovitrif]

Re-closing after task automation reopened this PR while producing a local APK. The supersession decision above remains unchanged: merged #1178 owns the production fix and regression coverage, so this PR stays closed without merge.

[ovitrif]

Fixes#1218

This PR persists successful amount validation for incoming on-chain Paykit Payment Requests, enabling the confirmation swipe only after the existing request validation and affordability checks pass.

Description

• Marks a valid, affordable incoming on-chain request amount as input-valid immediately before opening Send Confirm.
• Preserves the resolved endpoint, fixed request amount, private contact context, and existing acceptance ordering.
• Keeps invalid and unaffordable incoming requests blocked.
• Adds focused regression coverage and one user-facing changelog fragment.

Preview

QA Notes

Manual Tests

• 1. Pubky marketplace → open a valid incoming on-chain Payment Request: Send Confirm showed the seller, resolved endpoint, exactly 15,000 sats, and an enabled swipe on the exact PR head using a fresh arm64 regtest emulator.
• 2. Send Confirm → swipe to accept: the request broadcast exactly once as the sole mempool transaction with the exact 15,000-sat invoice output, confirmed after one regtest block, reached Paykit confirmed/1, completed Locks, and returned HTTP 200 for the guarded resource.
• 3. Invalid or unaffordable incoming on-chain Payment Request → open request: confirmation remains blocked.

Automated Checks

• AppViewModelSendFlowTest.kt: covers the payable resolved on-chain state, fixed request amount, endpoint, private contact context, and unaffordable block.
• just compile: passes.
• just test: passes all 2,267 tests.
• just lint: passes with existing baseline findings outside this change.
• ./gradlew assembleDevDebug: passes.
• Dev APK launch smoke on an isolated sdk_gphone64_arm64 regtest emulator: passes with MainActivity resumed and no fatal or ANR logs.

[greptile-apps]

Greptile Summary

This PR enables confirmation for validated, affordable incoming on-chain Paykit payment requests.

• Persists successful amount validation before opening Send Confirm.
• Adds regression coverage for payable and unaffordable incoming on-chain requests.
• Adds a user-facing changelog fragment.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/viewmodels/AppViewModel.kt	Marks the fixed incoming-request amount valid only after the existing validation and affordability checks succeed.
app/src/test/java/to/bitkit/viewmodels/AppViewModelSendFlowTest.kt	Adds focused coverage for successful on-chain confirmation state and rejection of an unaffordable request.
changelog.d/next/1221.fixed.md	Documents that affordable incoming on-chain payment requests can now be confirmed.

_{Reviews (3): Last reviewed commit: "fix: enable onchain request swipe (#1218..." | Re-trigger Greptile}

[ovitrif]

I am closing this PR as superseded by #1178. I created it from the live disabled-swipe defect observed on the then-current master; it supplied a one-line fix, focused regression coverage, and successful marketplace end-to-end evidence. The then-open #1178 already contained the production-equivalent fix e041150 and later merged it, together with positive regression 10ff0df, into master at 9698dea. My initial overlap check did not catch the matching change inside that open PR. This PR therefore no longer has an independent product deliverable, and retaining a conflicting branch only for incremental negative coverage is not warranted. No product behavior or validation evidence is lost.

[ovitrif]

Re-closing after task automation reopened this PR while producing a local APK. The supersession decision above remains unchanged: merged #1178 owns the production fix and regression coverage, so this PR stays closed without merge.

[ovitrif]

Fixes#1218

This PR persists successful amount validation for incoming on-chain Paykit Payment Requests, enabling the confirmation swipe only after the existing request validation and affordability checks pass.

Description

• Marks a valid, affordable incoming on-chain request amount as input-valid immediately before opening Send Confirm.
• Preserves the resolved endpoint, fixed request amount, private contact context, and existing acceptance ordering.
• Keeps invalid and unaffordable incoming requests blocked.
• Adds focused regression coverage and one user-facing changelog fragment.

Preview

QA Notes

Manual Tests

• 1. Pubky marketplace → open a valid incoming on-chain Payment Request: Send Confirm showed the seller, resolved endpoint, exactly 15,000 sats, and an enabled swipe on the exact PR head using a fresh arm64 regtest emulator.
• 2. Send Confirm → swipe to accept: the request broadcast exactly once as the sole mempool transaction with the exact 15,000-sat invoice output, confirmed after one regtest block, reached Paykit confirmed/1, completed Locks, and returned HTTP 200 for the guarded resource.
• 3. Invalid or unaffordable incoming on-chain Payment Request → open request: confirmation remains blocked.

Automated Checks

• AppViewModelSendFlowTest.kt: covers the payable resolved on-chain state, fixed request amount, endpoint, private contact context, and unaffordable block.
• just compile: passes.
• just test: passes all 2,267 tests.
• just lint: passes with existing baseline findings outside this change.
• ./gradlew assembleDevDebug: passes.
• Dev APK launch smoke on an isolated sdk_gphone64_arm64 regtest emulator: passes with MainActivity resumed and no fatal or ANR logs.

[greptile-apps]

Greptile Summary

This PR enables confirmation for validated, affordable incoming on-chain Paykit payment requests.

• Persists successful amount validation before opening Send Confirm.
• Adds regression coverage for payable and unaffordable incoming on-chain requests.
• Adds a user-facing changelog fragment.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/viewmodels/AppViewModel.kt	Marks the fixed incoming-request amount valid only after the existing validation and affordability checks succeed.
app/src/test/java/to/bitkit/viewmodels/AppViewModelSendFlowTest.kt	Adds focused coverage for successful on-chain confirmation state and rejection of an unaffordable request.
changelog.d/next/1221.fixed.md	Documents that affordable incoming on-chain payment requests can now be confirmed.

_{Reviews (3): Last reviewed commit: "fix: enable onchain request swipe (#1218..." | Re-trigger Greptile}

[ovitrif]

I am closing this PR as superseded by #1178. I created it from the live disabled-swipe defect observed on the then-current master; it supplied a one-line fix, focused regression coverage, and successful marketplace end-to-end evidence. The then-open #1178 already contained the production-equivalent fix e041150 and later merged it, together with positive regression 10ff0df, into master at 9698dea. My initial overlap check did not catch the matching change inside that open PR. This PR therefore no longer has an independent product deliverable, and retaining a conflicting branch only for incremental negative coverage is not warranted. No product behavior or validation evidence is lost.

[ovitrif]

Re-closing after task automation reopened this PR while producing a local APK. The supersession decision above remains unchanged: merged #1178 owns the production fix and regression coverage, so this PR stays closed without merge.

[ovitrif]

Fixes#1218

This PR persists successful amount validation for incoming on-chain Paykit Payment Requests, enabling the confirmation swipe only after the existing request validation and affordability checks pass.

Description

• Marks a valid, affordable incoming on-chain request amount as input-valid immediately before opening Send Confirm.
• Preserves the resolved endpoint, fixed request amount, private contact context, and existing acceptance ordering.
• Keeps invalid and unaffordable incoming requests blocked.
• Adds focused regression coverage and one user-facing changelog fragment.

Preview

QA Notes

Manual Tests

• 1. Pubky marketplace → open a valid incoming on-chain Payment Request: Send Confirm showed the seller, resolved endpoint, exactly 15,000 sats, and an enabled swipe on the exact PR head using a fresh arm64 regtest emulator.
• 2. Send Confirm → swipe to accept: the request broadcast exactly once as the sole mempool transaction with the exact 15,000-sat invoice output, confirmed after one regtest block, reached Paykit confirmed/1, completed Locks, and returned HTTP 200 for the guarded resource.
• 3. Invalid or unaffordable incoming on-chain Payment Request → open request: confirmation remains blocked.

Automated Checks

• AppViewModelSendFlowTest.kt: covers the payable resolved on-chain state, fixed request amount, endpoint, private contact context, and unaffordable block.
• just compile: passes.
• just test: passes all 2,267 tests.
• just lint: passes with existing baseline findings outside this change.
• ./gradlew assembleDevDebug: passes.
• Dev APK launch smoke on an isolated sdk_gphone64_arm64 regtest emulator: passes with MainActivity resumed and no fatal or ANR logs.

[greptile-apps]

Greptile Summary

This PR enables confirmation for validated, affordable incoming on-chain Paykit payment requests.

• Persists successful amount validation before opening Send Confirm.
• Adds regression coverage for payable and unaffordable incoming on-chain requests.
• Adds a user-facing changelog fragment.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/viewmodels/AppViewModel.kt	Marks the fixed incoming-request amount valid only after the existing validation and affordability checks succeed.
app/src/test/java/to/bitkit/viewmodels/AppViewModelSendFlowTest.kt	Adds focused coverage for successful on-chain confirmation state and rejection of an unaffordable request.
changelog.d/next/1221.fixed.md	Documents that affordable incoming on-chain payment requests can now be confirmed.

_{Reviews (3): Last reviewed commit: "fix: enable onchain request swipe (#1218..." | Re-trigger Greptile}

[ovitrif]

I am closing this PR as superseded by #1178. I created it from the live disabled-swipe defect observed on the then-current master; it supplied a one-line fix, focused regression coverage, and successful marketplace end-to-end evidence. The then-open #1178 already contained the production-equivalent fix e041150 and later merged it, together with positive regression 10ff0df, into master at 9698dea. My initial overlap check did not catch the matching change inside that open PR. This PR therefore no longer has an independent product deliverable, and retaining a conflicting branch only for incremental negative coverage is not warranted. No product behavior or validation evidence is lost.

[ovitrif]

Re-closing after task automation reopened this PR while producing a local APK. The supersession decision above remains unchanged: merged #1178 owns the production fix and regression coverage, so this PR stays closed without merge.

[ovitrif]

Fixes#1218

This PR persists successful amount validation for incoming on-chain Paykit Payment Requests, enabling the confirmation swipe only after the existing request validation and affordability checks pass.

Description

• Marks a valid, affordable incoming on-chain request amount as input-valid immediately before opening Send Confirm.
• Preserves the resolved endpoint, fixed request amount, private contact context, and existing acceptance ordering.
• Keeps invalid and unaffordable incoming requests blocked.
• Adds focused regression coverage and one user-facing changelog fragment.

Preview

QA Notes

Manual Tests

• 1. Pubky marketplace → open a valid incoming on-chain Payment Request: Send Confirm showed the seller, resolved endpoint, exactly 15,000 sats, and an enabled swipe on the exact PR head using a fresh arm64 regtest emulator.
• 2. Send Confirm → swipe to accept: the request broadcast exactly once as the sole mempool transaction with the exact 15,000-sat invoice output, confirmed after one regtest block, reached Paykit confirmed/1, completed Locks, and returned HTTP 200 for the guarded resource.
• 3. Invalid or unaffordable incoming on-chain Payment Request → open request: confirmation remains blocked.

Automated Checks

• AppViewModelSendFlowTest.kt: covers the payable resolved on-chain state, fixed request amount, endpoint, private contact context, and unaffordable block.
• just compile: passes.
• just test: passes all 2,267 tests.
• just lint: passes with existing baseline findings outside this change.
• ./gradlew assembleDevDebug: passes.
• Dev APK launch smoke on an isolated sdk_gphone64_arm64 regtest emulator: passes with MainActivity resumed and no fatal or ANR logs.

[greptile-apps]

Greptile Summary

This PR enables confirmation for validated, affordable incoming on-chain Paykit payment requests.

• Persists successful amount validation before opening Send Confirm.
• Adds regression coverage for payable and unaffordable incoming on-chain requests.
• Adds a user-facing changelog fragment.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/viewmodels/AppViewModel.kt	Marks the fixed incoming-request amount valid only after the existing validation and affordability checks succeed.
app/src/test/java/to/bitkit/viewmodels/AppViewModelSendFlowTest.kt	Adds focused coverage for successful on-chain confirmation state and rejection of an unaffordable request.
changelog.d/next/1221.fixed.md	Documents that affordable incoming on-chain payment requests can now be confirmed.

_{Reviews (3): Last reviewed commit: "fix: enable onchain request swipe (#1218..." | Re-trigger Greptile}

[ovitrif]

I am closing this PR as superseded by #1178. I created it from the live disabled-swipe defect observed on the then-current master; it supplied a one-line fix, focused regression coverage, and successful marketplace end-to-end evidence. The then-open #1178 already contained the production-equivalent fix e041150 and later merged it, together with positive regression 10ff0df, into master at 9698dea. My initial overlap check did not catch the matching change inside that open PR. This PR therefore no longer has an independent product deliverable, and retaining a conflicting branch only for incremental negative coverage is not warranted. No product behavior or validation evidence is lost.

[ovitrif]

Re-closing after task automation reopened this PR while producing a local APK. The supersession decision above remains unchanged: merged #1178 owns the production fix and regression coverage, so this PR stays closed without merge.

[ovitrif]

Fixes#1218

This PR persists successful amount validation for incoming on-chain Paykit Payment Requests, enabling the confirmation swipe only after the existing request validation and affordability checks pass.

Description

• Marks a valid, affordable incoming on-chain request amount as input-valid immediately before opening Send Confirm.
• Preserves the resolved endpoint, fixed request amount, private contact context, and existing acceptance ordering.
• Keeps invalid and unaffordable incoming requests blocked.
• Adds focused regression coverage and one user-facing changelog fragment.

Preview

QA Notes

Manual Tests

• 1. Pubky marketplace → open a valid incoming on-chain Payment Request: Send Confirm showed the seller, resolved endpoint, exactly 15,000 sats, and an enabled swipe on the exact PR head using a fresh arm64 regtest emulator.
• 2. Send Confirm → swipe to accept: the request broadcast exactly once as the sole mempool transaction with the exact 15,000-sat invoice output, confirmed after one regtest block, reached Paykit confirmed/1, completed Locks, and returned HTTP 200 for the guarded resource.
• 3. Invalid or unaffordable incoming on-chain Payment Request → open request: confirmation remains blocked.

Automated Checks

• AppViewModelSendFlowTest.kt: covers the payable resolved on-chain state, fixed request amount, endpoint, private contact context, and unaffordable block.
• just compile: passes.
• just test: passes all 2,267 tests.
• just lint: passes with existing baseline findings outside this change.
• ./gradlew assembleDevDebug: passes.
• Dev APK launch smoke on an isolated sdk_gphone64_arm64 regtest emulator: passes with MainActivity resumed and no fatal or ANR logs.

[greptile-apps]

Greptile Summary

This PR enables confirmation for validated, affordable incoming on-chain Paykit payment requests.

• Persists successful amount validation before opening Send Confirm.
• Adds regression coverage for payable and unaffordable incoming on-chain requests.
• Adds a user-facing changelog fragment.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/viewmodels/AppViewModel.kt	Marks the fixed incoming-request amount valid only after the existing validation and affordability checks succeed.
app/src/test/java/to/bitkit/viewmodels/AppViewModelSendFlowTest.kt	Adds focused coverage for successful on-chain confirmation state and rejection of an unaffordable request.
changelog.d/next/1221.fixed.md	Documents that affordable incoming on-chain payment requests can now be confirmed.

_{Reviews (3): Last reviewed commit: "fix: enable onchain request swipe (#1218..." | Re-trigger Greptile}

[ovitrif]

I am closing this PR as superseded by #1178. I created it from the live disabled-swipe defect observed on the then-current master; it supplied a one-line fix, focused regression coverage, and successful marketplace end-to-end evidence. The then-open #1178 already contained the production-equivalent fix e041150 and later merged it, together with positive regression 10ff0df, into master at 9698dea. My initial overlap check did not catch the matching change inside that open PR. This PR therefore no longer has an independent product deliverable, and retaining a conflicting branch only for incremental negative coverage is not warranted. No product behavior or validation evidence is lost.

[ovitrif]

Re-closing after task automation reopened this PR while producing a local APK. The supersession decision above remains unchanged: merged #1178 owns the production fix and regression coverage, so this PR stays closed without merge.

[ovitrif]

Fixes#1218

This PR persists successful amount validation for incoming on-chain Paykit Payment Requests, enabling the confirmation swipe only after the existing request validation and affordability checks pass.

Description

• Marks a valid, affordable incoming on-chain request amount as input-valid immediately before opening Send Confirm.
• Preserves the resolved endpoint, fixed request amount, private contact context, and existing acceptance ordering.
• Keeps invalid and unaffordable incoming requests blocked.
• Adds focused regression coverage and one user-facing changelog fragment.

Preview

QA Notes

Manual Tests

• 1. Pubky marketplace → open a valid incoming on-chain Payment Request: Send Confirm showed the seller, resolved endpoint, exactly 15,000 sats, and an enabled swipe on the exact PR head using a fresh arm64 regtest emulator.
• 2. Send Confirm → swipe to accept: the request broadcast exactly once as the sole mempool transaction with the exact 15,000-sat invoice output, confirmed after one regtest block, reached Paykit confirmed/1, completed Locks, and returned HTTP 200 for the guarded resource.
• 3. Invalid or unaffordable incoming on-chain Payment Request → open request: confirmation remains blocked.

Automated Checks

• AppViewModelSendFlowTest.kt: covers the payable resolved on-chain state, fixed request amount, endpoint, private contact context, and unaffordable block.
• just compile: passes.
• just test: passes all 2,267 tests.
• just lint: passes with existing baseline findings outside this change.
• ./gradlew assembleDevDebug: passes.
• Dev APK launch smoke on an isolated sdk_gphone64_arm64 regtest emulator: passes with MainActivity resumed and no fatal or ANR logs.

[greptile-apps]

Greptile Summary

This PR enables confirmation for validated, affordable incoming on-chain Paykit payment requests.

• Persists successful amount validation before opening Send Confirm.
• Adds regression coverage for payable and unaffordable incoming on-chain requests.
• Adds a user-facing changelog fragment.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/viewmodels/AppViewModel.kt	Marks the fixed incoming-request amount valid only after the existing validation and affordability checks succeed.
app/src/test/java/to/bitkit/viewmodels/AppViewModelSendFlowTest.kt	Adds focused coverage for successful on-chain confirmation state and rejection of an unaffordable request.
changelog.d/next/1221.fixed.md	Documents that affordable incoming on-chain payment requests can now be confirmed.

_{Reviews (3): Last reviewed commit: "fix: enable onchain request swipe (#1218..." | Re-trigger Greptile}

[ovitrif]

I am closing this PR as superseded by #1178. I created it from the live disabled-swipe defect observed on the then-current master; it supplied a one-line fix, focused regression coverage, and successful marketplace end-to-end evidence. The then-open #1178 already contained the production-equivalent fix e041150 and later merged it, together with positive regression 10ff0df, into master at 9698dea. My initial overlap check did not catch the matching change inside that open PR. This PR therefore no longer has an independent product deliverable, and retaining a conflicting branch only for incremental negative coverage is not warranted. No product behavior or validation evidence is lost.

[ovitrif]

Re-closing after task automation reopened this PR while producing a local APK. The supersession decision above remains unchanged: merged #1178 owns the production fix and regression coverage, so this PR stays closed without merge.