ENH: Change tapregext code to handle proposed use of forMode to allow specifying limits per mode

[stvoutsin]

Description

This is my attempt to provide client support for the proposal to add a forMode attribute to capabilities to allow specifying mode-specific (sync vs async) limits (executionDuration, retentionPeriod, outputLimit, and uploadLimit) as written in ivoa-std/TAPRegExt#10.

The current behaviour is that PyvVO will warn if more than 1 of these elements appears, which makes sense for the existing TAPRegExt spec.

Since this is still a PR in TAPRegExt I'll leave this as a Draft PR mainly for visibility and discussion. If we don't want this cluttering the PR list I could also move this into an issue and add a comment to refer to the branch with the changes.

Changes

Limit elements (executionDuration, outputLimit etc.) are now parsed into lists with new get_x(mode) methods for mode-aware getters.

One place I noticed that can take advantage of these mode-specific limits is the run_async timeout, so I've changed that to default to the service's advertised async execution duration as its wait timeout.

Compatibility

With the approach I've gone with existing code that depends on the singular limit properties (maxrec, and hardlimit) should be fine.

[codecov]

Codecov Report

❌ Patch coverage is 80.89888% with 34 lines in your changes missing coverage. Please review.
✅ Project coverage is 79.93%. Comparing base (828ea43) to head (3ca417a).
⚠️ Report is 11 commits behind head on main.

Files with missing lines	Patch %	Lines
pyvo/io/vosi/tapregext.py	73.58%	28 Missing ⚠️
pyvo/dal/tap.py	66.66%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #757      +/-   ##
==========================================
+ Coverage   79.79%   79.93%   +0.13%     
==========================================
  Files          91       91              
  Lines       10297    10424     +127     
==========================================
+ Hits         8217     8332     +115     
- Misses       2080     2092      +12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[msdemlei]

On Tue, May 26, 2026 at 10:55:37AM -0700, stvoutsin wrote: Since this is still a PR in `TAPRegExt` I'll leave this as a Draft

Oh dang, sorry I've let this slip. I've closed ivoa-std/TAPRegExt#8, and I'm pretty sure ivoa-std/TAPRegExt#10 is basically fine for merging. Would someone review it? Once it's in, I'd say we should just merge this. Ok, it's not in a REC yet, but then I'm rather sure nothing much will break if we do minor adjustments later, and we should really get the ball rolling properly.

[stvoutsin]

On Tue, May 26, 2026 at 10:55:37AM -0700, stvoutsin wrote: Since this is still a PR in TAPRegExt I'll leave this as a Draft
Oh dang, sorry I've let this slip. I've closed ivoa-std/TAPRegExt#8, and I'm pretty sure ivoa-std/TAPRegExt#10 is basically fine for merging. Would someone review it? Once it's in, I'd say we should just merge this. Ok, it's not in a REC yet, but then I'm rather sure nothing much will break if we do minor adjustments later, and we should really get the ball rolling properly.

Oh no problem, I had also forgotten about this one until now. I've added a couple of very minor comments to that TAPRegExt PR but as far as I'm concerned it looks ready to merge.