Would it be terrible if: we default to no readiness probe if the user doesnt ask for one

/area API
/area autoscale

## Describe the feature

Today, if a user doesnt specify a readiness probe we introduce a default (tcp) probe for them. Since #10741 this is run via both a startup probe (using an intermediate exec probe in queue proxy), and as a readiness probe which runs after the startup probe succeeds. The reason we do this is to avoid flakes when scaling up, ensuring the pod is at least ready to accept tcp connections before routing to it.

Before StartupProbe was available, running this as a ReadinessProbe was really the only way to accomplish this (readiness was the only game in town even tho we only _really_, I think, cared about startup flakes). However, now that we have StartupProbe it might be possible to _only_ run the tcp probe for the startupprobe, and then not run any readiness probe at all. This is technically a behaviour change since we would currently detect the pod going unready in this way after startup, but it (a) is a closer match to what the user actually asked for -- they didnt specify a probe at all, and wouldnt get one in raw k8s (b) would be a partial workaround for the issue in https://github.com/knative/serving/issues/10973 since we would avoid potentially missing the window to run the readiness probe after the startup probe completes (c) is simpler and more efficient (especially since, due to (b) we need the probe period to be as short as possible..). We also (d) might be able to do even better and do the startup probe in a PostStart lifecycle hook rather than an actual StartupProbe which _might_ fix https://github.com/knative/serving/issues/10973 entirely (while still avoiding flakes on scale-up).

Note: this is a rough thought for discussion. It may (well) have a fatal flaw I haven't spotted yet.

Start by tracing how Knative converts an unspecified probe into StartupProbe and readiness behavior, including the queue proxy path introduced by #10741; compare the implications described in #10973. Done means reaching a tested design decision on whether the implicit readiness probe can be omitted while preserving startup protection.

Written by the indexing model from the issue text.