feat: add priority-share admission control

[andylokandy]

Summary

• Add admission::PriorityShare as priority-bound handles over one shared capacity.
• Configure cumulative admission thresholds through per-priority capacity increments.
• Apply strict priority across levels and fair sharing between owners at the same priority.
• Implement FairShare as the equivalent single-priority policy over the same scheduler.
• Provide borrowed and owned acquisition APIs, custom hash builders, priority-scoped availability observations, model-based tests, and concurrency stress coverage.

Compatibility note: this removes the public FairShare::num_waiters() method introduced in v0.6.5.

Design Notes

Priorities are dense zero-based values ordered from lowest to highest. The constructor returns one handle per configured priority, and acquisition methods use the priority bound to that handle.

Capacity entries represent incremental headroom. The admission limit for priority p is the sum of entries through p, while every assigned permit counts toward every applicable shared threshold. For example, with [4, 1], priority 0 can enter while fewer than four permits are assigned, and priority 1 while fewer than five are assigned.

When capacity is released, the highest eligible priority is admitted first. Within that priority, the owner holding the fewest permits across all priorities is selected; ties follow queue order. The same owner may acquire or wait at multiple priorities.

Assigned permits are never revoked. Sustained higher-priority demand may starve lower priorities, and reserved headroom may remain unused while lower-priority work waits.

PriorityShare::available_permits() is scoped to its handle’s priority. Values from different handles overlap and must not be added together; the highest-priority handle reports total unassigned capacity.

[tisonkun]

Under this design we may merge FairShare into PriorityShare because FairShare::new(n) is semantically identicial to PriorityShare::new([n]).