Show namespace shortcuts in the header, k9s-style

[MichaelKlank]

Problem

1-9 already select a namespace and 0 selects all namespaces, but the
mapping is only visible inside the namespace popup (n). On the resource
table -- the one view where those keys apply -- there is no way to see which
digit goes where, so the shortcuts are effectively undiscoverable. k9s keeps
this mapping permanently in the header, which is where people coming from k9s
look for it.

The digits also do nothing at all until favorite_namespaces is configured,
which most users never find either.

Proposal

1. A namespace shortcut column in the full header: 0 <all> plus every bound
   digit, with the active namespace highlighted. It is the first block dropped
   when the terminal narrows, since n still lists the same mapping while the
   per-kind hints have no second home.
2. 1-9 fall back to the namespaces you visit for the slots
   favorite_namespaces leaves open, so the digits do something out of the
   box. A configured favourite never loses its slot.
3. One shared accessor behind the key handler, the header and the popup, so
   what the header shows is always what the key does.

Open questions

• Does this fit sofka at all? The header is already dense, and the
  information is available in n. If the answer is "the switcher is enough",
  that is a fine outcome and I will drop it.
• Slot stability. k9s reassigns the digits as its recent list reorders, so
  a digit can point at a different namespace the next time you look. That
  seemed wrong for a mapping the header advertises permanently, so the
  prototype hands a slot out once and keeps it: a new namespace takes a free
  slot, and only a full list gives one up -- that of its least recently used
  entry. Is that the behaviour you want, or would you rather match k9s exactly?
• Width. The block needs about 20 columns next to the info cluster and the
  key hints, 40 for a second column once more than five digits are bound. Below
  that it folds away entirely. Is folding acceptable, or should it be a config
  toggle instead?
• Scope. Header only, or would you also want the shortcut mapping in the
  compact header (ctrl-e)? The prototype leaves compact mode untouched.

Status

I have a working prototype in #469, including docs and tests. That was out of
order -- AGENTS.md asks for the discussion first, and I opened the PR before
this. Happy to close it, rework it to whatever scope is agreed here, or leave
it as a reference for what the change looks like in practice.

[nklmilojevic]

Configured namespace shortcuts are already shown beside Namespace: in the full header, with the active namespace highlighted. The list adjusts to the available width.

I would keep 1–9 tied to configured favourites so their targets stay predictable, and keep recent namespaces in the n switcher. I do not plan to add a separate header column or automatic shortcut assignment.

[MichaelKlank]

Thanks — I see the inline shortcuts next to Namespace: in main now. That
covers the discoverability problem I opened this for, width adaptation and
unbound slots included, so the separate header column is settled: dropped, no
argument from me.

On the automatic assignment I would like to make the case once, then leave it
with you. The colleagues who introduced me to sofka, and the ones I have since
introduced to it, asked for exactly this feature independently of each other.
They have been running my build to test it and find it genuinely useful in
daily work. The friction is that favorite_namespaces has to be found in the
docs before 1-9 do anything at all, and the namespaces a team works in
change more often than people go and edit their config.

Your predictability concern is the reason the branch deliberately does not
follow k9s: a slot is handed out once and then kept. A namespace that has a
digit keeps it, a new one takes a free slot, and only once every slot is taken
does one get handed over — the least recently used. So the digits do not move
around while you work.

Would a config toggle be an acceptable compromise? Default off, so nothing
changes for you and 1-9 stay exactly as predictable as they are today; when
enabled, only the slots no favourite claims get filled with visited namespaces.
Then everyone configures the behaviour they want and the predictable default
stays the one you prefer.

If the answer is still no, that is a fine outcome — I will keep it on my fork
and stop pushing it.

[MichaelKlank]

Rebuilt the branch on current main so the compromise can be judged as code
rather than as a proposal:
https://github.com/MichaelKlank/sofka/tree/feat/namespace-shortcut-header

Your header work made most of it unnecessary. favorite_namespace_spans and
App::favorite_namespace already carry the display and give a single seam, so
the separate header column and its layout code are gone entirely. What is left
is one commit:

• auto_namespace_shortcuts, default false. Off, namespace_shortcuts()
  returns the configured favourites and nothing else — byte for byte today's
  behaviour, and all 1546 tests on main pass untouched.
• On, the namespaces you visit claim the slots the favourites leave open. A
  slot is handed out once and kept: picking a namespace never moves another
  one's digit, and only when every slot is taken does one change hands — the
  least recently used. That is the part that differs from k9s, and it is what
  addresses your predictability concern.
• The header, the switcher badge and the key handler all read the same list,
  so the advertised mapping cannot drift from what the key does.

Six tests, including one that asserts both sides of the switch, and the docs
for the option.

No PR — you closed the last one and I am not going to reopen the question
behind your back. If the toggle is not something you want in sofka either,
say so and I will keep it on the fork; that is a perfectly good outcome and
the branch stays useful to me and the colleagues testing it.

One thing from the branch is worth having regardless of this feature, so it is
its own PR: #548 fixes :<kind> all recording the literal all as a recent
namespace.