I think you'll find the Script Runners section of the Protected Audience (PA) specification describes how the execution environment that PA bidding and scoring scripts run in differs from the Web's Worklet definition.
WRT your "1." question: due to these differences, I think it's unlikely that PA bidding and scoring Script Runners will become standard worklet types.
WRT your "2." question: PA bidding and scoring Script Runners are not built off of the shared storage worklet or any other worklet.

So would it make sense to actually use the term script runner for worklet. Isn't that more technically accurate since the actual W3 spec says they are different? Here's an example from the FLEDGE explainer where using the worklet term is confusing:

"All the logic of the on-device auctions will execute inside a collection of dedicated worklets. Each worklet is associated with a single domain, and runs code written by either a buyer or a seller.... We will publish a separate explainer on dedicated worklets."

Change to:

All the logic of the on-device auctions will execute inside a collection of dedicated environments similar to worklets called script runners. Each script runner... blah blah... and so on...We will publish a separate explainer on dedicated script runners for the Protected Audiences API"

Script runners has link to "https://wicg.github.io/turtledove/#script-runner"

Apologies for hijacking this thread, but I think my issue is close enough. I am interested in worklets aka script runner performance and their basic characteristics. For example: what is the worklet warmup time? Do worklets for the same buyer, seller, interest group or origin execute sequentially or in parallel? What are the limits of parallelization? What are the resources available to each worklet? How does worklet re-use work exactly? How is this related to Interest Group's execution mode? I can see there's a big TODO in the spec on the last one.

Thanks!