Investigate: Handling custodialOffice from Put Back On processor

In `src/business_filer/filing_processors/put_back_on.py` there is a lookup and removal of Custodial Office.

~~Since those do not apply the PBO doesn't need to handle these~~ (TBD)

---

**Edit:**
After looking into a bit some migration/previous-data questions come up that need answering first in terms of business requirement:

1. If a dissolved company is tombstone migrated in from Colin (or has already been) then it **will** insert into Lear a **custodianOffice** row. Then if the company is Put Back On it would remove that Custodial Office (delete row). If we take that away then PBOing a migrated corp would _leave_ the Custodial Office.
**The current PBO processor removes that custodialOffice row from offices, should that just be left alone then?**

Note in a Restoration it implicitly removes any Custodial Office since it deletes offices and only re-adds the known ones from the filing. So there's a minor discrepancy in the 2 filings processors but right now they both would remove a hanging Custodial Office (just the PBO is explicitly referencing it)

Start in src/business_filer/filing_processors/put_back_on.py and inspect the Custodial Office lookup and removal. Clarify the business requirement for tombstone-migrated companies and whether Put Back On should retain or delete the custodialOffice row, then compare the intended behavior with Restoration; done means the requirement and processor behavior are agreed.

Written by the indexing model from the issue text.