android: device pins/favorites and match iOS long push menu

[hiimtmac]

Adds support for device pinning - from device list and from peer detail
Match iOS long push menu - ipv4/ipv6/magic DNS, update icon and reorder

Fixes https://github.com/tailscale/corp/issues/47581
Fixes https://github.com/tailscale/corp/issues/47582

Screen_Recording_20260904_110411.mp4

[barnstar]

Looks good - just one small issue with the write serialization. I think we should also add the long press gesture the the search results if that's possible - though we can do that in a follow-up.

[kari-ts]

thanks! this mostly looks good. I'm curious about what happens if a profile switch happens if there is an in-flight write. iiuc, the LocalAPI write doesn't get canceled. in a profile switch, could e.store be switched to that of the new profile before an older pins request under the previous profile is completed?

[hiimtmac]

thanks! this mostly looks good. I'm curious about what happens if a profile switch happens if there is an in-flight write. iiuc, the LocalAPI write doesn't get canceled. in a profile switch, could e.store be switched to that of the new profile before an older pins request under the previous profile is completed?

I couldn't find any other coordination between inflight LocalAPI writes and switching profiles in android. I agree that this is a valid concern but I think it should probably be addressed at the project level (rather than a custom implementation for favourites alone). AFAICT the iOS/macOS impl also lack the coordination so potentially this could be solved at the shared go/LocalAPI level instead? Id propose a project-wide follow up for shoring up this pattern everywhere it can be applied to - wdyt?

[kari-ts]

thanks! this mostly looks good. I'm curious about what happens if a profile switch happens if there is an in-flight write. iiuc, the LocalAPI write doesn't get canceled. in a profile switch, could e.store be switched to that of the new profile before an older pins request under the previous profile is completed?

I couldn't find any other coordination between inflight LocalAPI writes and switching profiles in android. I agree that this is a valid concern but I think it should probably be addressed at the project level (rather than a custom implementation for favourites alone). AFAICT the iOS/macOS impl also lack the coordination so potentially this could be solved at the shared go/LocalAPI level instead? Id propose a project-wide follow up for shoring up this pattern everywhere it can be applied to - wdyt?

yep, I agree with this!

Addressed feedback