feat: add network column to schema for multi-network support

[silent-cipher]

Summary

Introduces a network column to the core runtime tables so a single dealbot instance can safely operate across both calibration and mainnet without collisions between same-address providers/deals on different chains.

Step towards #297

[Copilot]

Pull request overview

Adds network scoping to core runtime tables so a single backend instance can operate against both calibration and mainnet without address/deal collisions.

Changes:

• Introduces network columns and updates PK/FK/unique constraints to be network-aware (migration + entity updates).
• Updates several upsert/conflict targets to include network for correct deduplication across chains.
• Adds SUPPORTED_NETWORKS constant and updates unit tests to reflect conflict key changes.

Reviewed changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
apps/backend/src/database/migrations/1776790420000-AddNetworkColumn.ts	Adds network columns, updates PK/FK/unique constraints and supporting indexes for multi-network isolation.
apps/backend/src/database/entities/storage-provider.entity.ts	Makes StorageProvider primary key composite (address, network).
apps/backend/src/database/entities/deal.entity.ts	Adds network column and updates SP relation join to (sp_address, network).
apps/backend/src/database/entities/job-schedule-state.entity.ts	Adds network column (but currently leaves unique index definition misaligned with new schema).
apps/backend/src/database/entities/data-retention-baseline.entity.ts	Makes baseline primary key composite (provider_address, network).
apps/backend/src/wallet-sdk/wallet-sdk.service.ts	Updates provider upsert conflict target to include network.
apps/backend/src/wallet-sdk/wallet-sdk.service.spec.ts	Updates unit test to expect network-aware conflict paths.
apps/backend/src/jobs/repositories/job-schedule.repository.ts	Updates job schedule upsert conflict target to include network.
apps/backend/src/data-retention/data-retention.service.ts	Updates baseline upsert conflict columns to include network.
apps/backend/src/data-retention/data-retention.service.spec.ts	Updates unit test to expect network-aware conflict columns.
apps/backend/src/common/constants.ts	Adds SUPPORTED_NETWORKS constant used by the migration.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[SgtPooki]

Looks like there are just a few more gaps, and we need to make sure runtime reads pull from the correct network-scoped records. Pass network in the relevant DB read functions and make sure it’s handled in the appropriate repository/query logic.

[SgtPooki]

I couldn't see anything wrong at first glance, so I threw gemini + claude + codex at it and they uncovered potential gaps.. I'm testing locally and will get back with findings.

[silent-cipher]

I'm finding it a bit tricky to define the scope of this pr and where to draw the boundary for changes. My initial thought was to split the work between this pr and #468 so we could roll out smaller prs. Would you prefer that approach, or should I instead consolidate everything from #468 into this pr and make it a single change?

[SgtPooki]

@silent-cipher yea, i think the idea of a schema-only PR change would be ideal, and keeping PRs small, but this PR already does some application level piping through of data. as a minimum, I think we need #510 on top of this (or similar if you recommend differently)

I don't want to disrupt you too much, so let me know what you think would be best

[silent-cipher]

I’m thinking of splitting this into three PRs to keep things small and backward compatible -

• a schema-focused pr(this one), including changes from fix(network): close multi-network gaps before #297 expansion #510, and I’ll verify if anything else is needed there
• a pr to update prometheus metrics with the network label
• a final pr for env/config schema updates along with the relevant use cases and docs