fix(ingest): Guard against muxed/memo id values exceeding i64::MAX instead of silently dropping attribution

[Emmyt24]

Description

As identified by the related boundary-testing issue, Ingestor::muxed_id/memo_id in crates/ingest/src/lib.rs silently return None (treating the deposit as unattributed/quarantined) when a muxed id or memo id exceeds i64::MAX and fails i64::try_from. Since addresses.muxed_id is a BIGINT (signed 64-bit) per crates/store/migrations/0001_init.sql, octo itself will never assign an id that high (Store::allocate_address's counter starts at 1 and increments), so this can only happen for a memo/muxed id an external sender chose themselves (e.g. sending to a muxed address not derived from an octo-assigned id, or a hand-crafted huge memo). Silently quarantining is arguably correct, but it currently happens with no log signal distinguishing it from an ordinary 'no matching address' quarantine, making it hard to tell the two apart operationally.

Requirements and Context

• When i64::try_from fails specifically due to overflow (as opposed to the id simply not matching any registered address), emit a distinct tracing::warn! noting the raw u64 value and the wallet/tx hash, so this out-of-range case is operationally distinguishable from an ordinary unattributed deposit in logs.
• Do not change the recorded outcome (it should still be quarantined, per the existing Processed::Recorded { attributed: false } / quarantine convention) — this ticket only improves observability of why it was quarantined.

Suggested Execution

Branch: fix/ingest/guard-id-overflow-visibility

Implement Changes

• Update Ingestor::muxed_id/memo_id (or process, wherever fits best without disrupting their current pure-function shape used by the existing unit tests) in crates/ingest/src/lib.rs to log distinctly on overflow.

Test and Commit

• overflowing_muxed_id_logs_a_distinct_warning_and_is_still_quarantined (assert on the outcome; a log-content assertion may require a test tracing subscriber — use tracing_test or similar if the workspace doesn't already have a log-capture helper, or assert behaviorally and note the log expectation in a comment if capturing log output isn't practical here).
• Run cargo test -p octo-ingest locally before committing.

Example Commit Message

fix(ingest): log distinctly when a muxed/memo id overflows i64 instead of silently quarantining

An id above i64::MAX was already correctly quarantined but with no way to
tell it apart from an ordinary unattributed deposit in logs. Adds a distinct
warning for the overflow case specifically, with no change to the recorded
outcome.

Guidelines

• Keep this a logging-only change — the actual quarantine behavior for out-of-range ids is intentional and should not change here.
• Reference this issue with Closes #<issue-number> in the PR description.

[ugoocreates-pixel]

I will solve this issue well and submit pr today

[grantfox-oss]

🦊 GrantFox — @ugoocreates-pixel has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #99)
2. Your PR will be reviewed by the Octo-Protocol-org maintainers

Good luck! Track your progress on GrantFox.