Fix first-run onboarding: README/wiki quickstart + StatusWidget MonitorTag crash

[HanSur94]

Fixes the FastSense first-run experience, surfaced by simulating a brand-new user installing from a clean slate (git archive HEAD → fresh matlab -batch with restoredefaultpath) and copy-pasting the README / wiki snippets verbatim. Every primary onboarding path now works end-to-end.

What was broken

• README "The core idea: Tags" threw on copy-paste: t/pressure_data were undefined, and TagRegistry.register(press) used the wrong arity (the real API is two-arg register(key, tag) — used by the class docstring and ~40 call sites; the README was the only one-arg user).
• README "Build a dashboard" threw twice: widgets take 'Title', not the invalid 'Label' option; and binding a status widget to a MonitorTag via 'Tag' crashed at render with Unrecognized method, property, or field 'Y' for class 'MonitorTag'.
• wiki/Installation.md pointed newcomers at libs/FastPlot (renamed to libs/FastSense; the optional cd libs/FastPlot step errored) and listed only 5 of the 9 libs install adds.
• wiki/_Sidebar.md was still branded "FastPlot Wiki".
• example_basic (the first example a newcomer runs) printed a spurious Negative limits ignored warning when switching to a log Y axis after render.

Changes

Area	Fix
README.md	Tags snippet made self-contained + correct two-arg register; dashboard widgets use 'Title'
libs/Dashboard/StatusWidget.m	Constructor routes a 'Tag'-bound monitor-kind Tag to the Threshold/monitor path (deriveStatusFromMonitorTag_) instead of the SensorTag-only obj.Sensor.Y access. Backward compatible; brings StatusWidget to parity with MultiStatusWidget
tests/suite/TestStatusWidget.m	New testRefreshWithMonitorTag (violation + ok cases)
examples/01-basics/example_basic.m	Set log scale before render() so the axis autoscales in log space — no warning
wiki/Installation.md, wiki/_Sidebar.md	libs/FastPlot → libs/FastSense, complete the added-paths list, fix wiki branding

Verification (fresh MATLAB process, restoredefaultpath)

• README path end-to-end: "30 seconds in" + Tags + Dashboard + save/load round-trip (4 widgets) — clean.
• Getting-Started tutorial: 13/13 snippet sections.
• Sensor + dashboard examples: 10/10.
• TestStatusWidget + TestMultiStatusWidget + TestMultiStatusWidgetTag: 23/23 (new test was RED before the fix, GREEN after).
• Regression — TestDashboardSerializerRoundTrip + TestDashboardBugFixes + TestDashboardPreview + TestInfoTooltip: 68/68.
• Octave first-run path: install + render verified.

Toolbox-free and backward-compatible throughout; pure-MATLAB MEX fallback untouched.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[HanSur94]

CI analysis — both red checks are pre-existing / flaky, not from this PR

MATLAB Tests (Dashboard) — TestDashboardTimeWindow/testPreviewStillFull
(getTimeRange tMax=739256 should reflect full extent end ~739261).
This fails identically on main (today's scheduled run 28314859799, same test, same numbers). The test exercises only FastSenseWidget('Tag', sensorTag) — it never constructs a StatusWidget or MonitorTag — so nothing in this PR can affect it. Pre-existing.

MATLAB Tests (Q-Z) — TestTagPerfRegression/testConsumerMigrationTickGate
(errored in bench_consumer_migration_tick). This is a performance benchmark that passes on main and flakes under CI load; this PR touches no Tag-pipeline / perf code. Re-triggered the failed jobs to confirm.

This PR's own test passed: the Q-Z log shows Running TestStatusWidget … Done TestStatusWidget with no failures, and codecov reports all modified lines covered.

Net: this PR introduces no test regressions. The Dashboard red is a pre-existing main failure (out of scope here); the Q-Z red is a flaky perf gate.

🤖 Analysis by Claude Code

[HanSur94]

Parked as draft pending a maintainer decision — to stop the repeated CI-failure notifications, not because anything is wrong with the change.

Only failing check: MATLAB Tests (Q-Z) → TestTagPerfRegression/testConsumerMigrationTickGate (bench_consumer_migration_tick:regression, a 10% tick-overhead budget). This is a flaky timing gate, not a regression from this PR:

• The benchmark exercises only FastSenseWidget ('Sensor' vs 'Tag' halves) — no StatusWidget, so this PR's code cannot affect it. The getTimeRange fix takes the zero-cost path (no TimeWindow_ in the bench) and already passes the gate on main/fix(dashboard): getTimeRange returns full data extent under an active TimeWindow #284.
• Same machine, back-to-back: origin/main measured −62% overhead (pass) while this branch measured +20% (fail), with legacy time swinging 1336→469 ms — i.e. the metric is dominated by runner load, and a 10% gate can't survive that.

All real tests are green: Dashboard (fixed by the merged #284 getTimeRange fix), A-D, E-I, J-P, Octave, TestStatusWidget, and codecov (all modified lines covered).

To proceed: mark ready + merge (the gate is a proven false-positive), or the perf gate can be made robust separately (warmup + best-of-N, realistic budget) to end the flakiness for good.

🤖 Status by Claude Code

[HanSur94]

Wiki docs updated to reflect the StatusWidget MonitorTag-via-'Tag' fix from this PR: #368

• wiki/API-Reference:-Dashboard.md — added the MonitorTag-bound-via-'Tag' usage form to the StatusWidget summary
• wiki/Dashboard-Engine-Guide.md — added a matching example to the Status widget section

(wiki/Installation.md and wiki/_Sidebar.md were already updated directly in this PR.)

---

Generated by Claude Code